Compliance assurance

1. Payments · PCI DSS

On-site membership and commission payments (Pro plan) are processed by Stripe, a PCI DSS Level 1 service provider. Card data is entered into Stripe-hosted fields and goes directly to Stripe; it never passes through or is stored on vtstreamer.com systems. This keeps the Service within the scope of SAQ A, the lightest self-assessment. We have completed the SAQ A self-assessment; no approved scanning vendor (ASV) scan is currently run. Creators using Fourthwall, Gumroad, Ko-fi, Throne, Patreon, Twitch or YouTube for money never touch card data through us at all.

2. Privacy · GDPR, UK GDPR, CCPA/CPRA and friends

What we collect, why, and for how long is set out on the Privacy page. The statement of which data-protection laws apply to the Service, and on what basis, has not been published yet; this page does not claim that any of those regimes is met.

3. Online safety

Fan-art submissions are moderated by the Creator before publication, never after. A submission is held where no public address can reach it, is rebuilt and checked as described under Security below, and then waits in a queue until the Creator approves it. Creators can block a handle from submitting at all, and blocking also hides anything that handle sent previously.

A visitor can report any fan-art piece on a Creator's gallery with the “report this piece” form. A reported piece is hidden at once and stays hidden until the Creator reviews it, and hiding is reversible. Reports are rate-limited per visitor. This covers fan art only: there is no public route for reporting anything else on a site, or for following what was done about a report.

Where this page describes a control as planned rather than running, it says so — we would rather be dull and accurate than claim a protection we do not have.

4. Security

Every image uploaded to this platform — a Creator's own artwork and a visitor's fan-art submission alike — is taken apart and rebuilt before anyone can see it. We decode it to raw pixels and encode a brand-new file from those pixels alone. Nothing from the file you sent is carried over: not its metadata, not its container, not anything hidden after the end of the image.

That closes four specific classes of attack, and we name them because most platforms do not. Polyglot files — a single file that is a valid image and a valid script or archive at the same time — do not survive being rebuilt from pixels. Appended payloads, where data is bolted on after the image data ends, are discarded with the rest of the original container. Decompression bombs, images whose few kilobytes expand to gigabytes when decoded, are refused before decoding starts, by limits on pixels, dimensions and animation frames. And metadata leaks are eliminated: EXIF, XMP, IPTC and colour-profile blocks all go, including GPS coordinates, camera serial numbers, and the embedded EXIF thumbnail, which routinely still contains the uncropped original of a picture somebody cropped before sending it.

The decoding itself is the risky part — image libraries are where image vulnerabilities live — so it runs in a short-lived, isolated process with a memory ceiling and a time limit, holding no database access and no storage credentials. If it is ever exploited, what it holds is one image. Uploads wait in storage that no public address can reach until they have been through all of this, and only then are they moved somewhere servable.

What we do not claim: we do not currently run signature-based malware scanning or automated nudity and violence classification on uploads. Creators moderate their own fan-art queues, and nothing a visitor submits appears on a Creator's site until that Creator approves it.

5. Accessibility

We test this rather than assert it. On 2026-09-29, axe-core's WCAG 2.2 Level A and AA rule set found no violations across all 14 admin screens, the sign-in and onboarding pages and all 7 public creator pages, on a production build with a signed-in account. The same run checked 475 interactive elements and found every one reachable by keyboard with a visible focus indicator. That check runs on every change we make, and a new violation fails the build.

Three things that test cannot tell you, which we would rather say than let the paragraph above imply. Automated rules reach roughly a third of WCAG AA: they judge contrast, names and structure well, and cannot judge whether a focus order makes sense or an error message helps. No independent expert has audited us, so this is a measurement and not a certification. And the theme editor warns when a colour pairing falls below the level the standard asks for — 4.5:1, or 3:1 where the text is large — and offers to correct it. It checks every surface a Creator's page actually paints, which it did not before 2026-09-29. It does not prevent publishing: the site is the Creator's, and a tool that refused to publish their chosen colours would be deciding for them. So a Creator can publish a theme we would flag, and we tell them which colour to change and by how much.

Images on creator sites carry descriptive alternative text that we generate, from the artist credit or the Creator's display name. There is not yet a field for a Creator to write their own, which is a gap rather than a decision.

This helps Creators meet the EU Accessibility Act, the UK Equality Act and the ADA, but a Creator's own content remains their responsibility.

9. What we don't certify

We do not audit Creator content, guarantee the legality of what a Creator sells, or certify third-party platforms (Twitch, YouTube, Discord, Cloudflare, Stripe and others follow their own compliance programmes).

This prototype text is a starting point for counsel, not legal advice.