Every acquirer, PSP and payment facilitator with exposure to user-generated adult content knows the headline obligations: age and identity verification for everyone depicted, documented consent, pre-publication review, a complaints route, monthly reporting. Those have been settled since 2021. What has changed since is not the list. It is who is held to it, and how quickly you are expected to prove it.
The short version: the schemes do not audit your merchant. They audit you. The merchant holds the consent records; you hold the obligation to certify that those records exist and are adequate — usually without any independent way to test the claim until a review is already underway.
The rules are addressed to you
This is the structural point that gets lost when these requirements are summarised as merchant obligations. Read the underlying texts and the addressee is the acquiring side.
Mastercard's requirements, introduced through AN 5196 and effective from 15 October 2021, now sit in Section 9.4.1 of the Mastercard Rules. The operative construction is that acquirers must certify that their adult content merchants permit uploads only from verified content providers, that those merchants run a robust process for verifying the age and identity of content providers against government-issued ID, and that every person depicted has been age-and-identity verified with documented consent. The certification duty is yours. The records sit somewhere else.
Visa's Integrity Risk Program, which replaced the Global Brand Protection Programme in 2023, is even more explicit about where it is pointed. VIRP requires the acquirer to hold High Integrity Risk Acquirer Registration before soliciting, contracting with or processing for any merchant in a high-integrity-risk category. Adult content under MCC 5967 sits in Tier 1, which carries separate and additional Visa approval per category and periodic control assessments of the acquirer's own oversight processes. The unit being assessed is your control environment, not any individual merchant's paperwork.
| Requirement | Who the scheme holds to it |
|---|---|
| Age and identity verification of every person depicted | Merchant performs — acquirer certifies |
| Documented, unambiguous consent from every person depicted | Merchant collects — acquirer certifies |
| Verified content providers only, under written agreement | Merchant operates — acquirer certifies |
| Pre-publication content review; real-time control of live content | Merchant operates — acquirer evidences on request |
| Complaint and appeal route for depicted persons | Merchant operates — acquirer evidences on request |
| Monthly reporting of flagged content, complaints and takedowns | Merchant produces — acquirer receives and forwards to the scheme |
| Registration and periodic control assessment | Acquirer, directly |
Mastercard's Merchant Monitoring Program, revised effective January 2026, pushes the same logic further into continuous territory. The programme governs how acquirers monitor merchants over time, which shifts the failure mode from a single bad merchant to a systemic monitoring gap on your side of the relationship — and a single non-compliant merchant can draw scheme-level attention across a portfolio.
The attestation gap
Here is the operational problem, stated plainly. When you onboard or review an adult content merchant, you ask whether they hold age, identity and consent records for every person appearing in every monetised asset. They tell you they do. You have no practical way to test that answer.
You are certifying to a scheme, on your own licence, a claim you have accepted on trust and cannot independently verify until the day someone asks you to produce it.
A sampling exercise does not close this. You can ask for the file on three scenes and receive three tidy PDFs. That tells you those three exist. It tells you nothing about the fourteen thousand others, the shoot from 2022 where a second person appeared in frame, or the collaboration where a visiting performer signed something on a phone and was never entered into the merchant's system at all. The coverage question — every asset, every person — is exactly the one a sample cannot answer.
None of this implies bad faith on the merchant's part. Most platforms in this sector are trying hard and spending real money on compliance. The issue is that the artifact they produce was never designed to be verified by a third party. It was designed to be stored.
Four ways a merchant's consent file falls short as evidence
A typical file for a given asset contains a signed release and a scan of a government ID. It looks complete. Under review it has four specific weaknesses, and each maps onto a question you will be asked.
- It evidences a document, not a person. A scanned ID next to a handwritten signature demonstrates that someone possessed a document and wrote a name. It does not demonstrate that the person in the content is the person on the document, that they were the one who signed, or that anybody checked. Absent a biometric binding, the strongest claim available is that paperwork was collected.
- It is indexed by person, not by asset. The scheme rules bind at the level of the individual piece of content. Merchant record-keeping is almost always organised by performer or by shoot. When a review asks for the consent chain behind one specific URL, that mismatch is where the delay comes from — and delay reads to a reviewer as absence.
- It records a moment, not a state. Both schemes require a live route for a depicted person to request removal, with resolution inside a defined window. A file that proves consent was given in March 2023 cannot tell you whether that consent still stands today. The obligation is continuous; the artifact is static.
- It is a data liability in its own right. To hold that file, the merchant holds copies of identity documents for every performer they have ever worked with — a concentrated store of exactly the data that turns an ordinary security incident into a regulatory one, sitting inside your portfolio.
The deadlines do not stack. They compete
A merchant receiving a removal request in 2026 is not working to one clock. Mastercard's framework expects complaints alleging illegal or non-consensual content to be resolved within seven business days. The TAKE IT DOWN Act, whose notice-and-removal provisions took effect on 19 May 2026, requires covered platforms to remove non-consensual intimate imagery, and make reasonable efforts to remove known identical copies, within 48 hours of a valid request — enforced by the FTC, with civil penalties running to tens of thousands of dollars per violation. Visa's programme adds its own expectations.
For any given report, the strictest applicable deadline governs. That has a consequence which is easy to miss at portfolio level: a merchant whose consent records take four days to locate has already failed the tightest of those windows before anyone has made a decision about the content. The binding constraint is no longer whether the evidence exists. It is retrieval latency.
Note also the shape mismatch between the two regimes. Mastercard expects review before publication. TAKE IT DOWN operates on removal after notification. Satisfying the federal standard does not satisfy the scheme standard, and a merchant who has built only a post-notification takedown process is compliant with one and exposed on the other.
What a failure actually costs the portfolio
The consequences do not arrive one at a time, which is the part that makes this worth pricing properly. A single substantiated complaint about non-consensual content can simultaneously trigger a scheme compliance case, an acquirer-imposed fine passed through to the merchant, a reserve increase, a VIRP control assessment finding against your registration, federal civil exposure for the merchant under TAKE IT DOWN, and — where the merchant is terminated — a MATCH listing that follows them for five years.
Layer onto that the direction of travel on dispute monitoring. Thresholds under Visa's acquirer monitoring framework have tightened materially through 2025 and 2026, and adult portfolios are structurally exposed to friendly-fraud disputes. A portfolio already running close to a monitoring threshold has very little tolerance left for a content compliance case arriving on top.
The dates that matter
Mastercard AN 5196 takes effect. Acquirer certification of adult content merchant controls begins; requirements now sit in Section 9.4.1 of the Mastercard Rules.
Visa's Integrity Risk Program replaces the Global Brand Protection Programme. Adult content under MCC 5967 sits in Tier 1, requiring acquirer registration, per-category approval and periodic control assessments.
Mastercard's revised Merchant Monitoring Program takes effect, formalising continuous acquirer oversight obligations rather than point-in-time checks.
TAKE IT DOWN Act notice-and-removal provisions become enforceable. Covered platforms must operate a removal process and act within 48 hours. FTC enforcement begins.
Dispute and fraud monitoring thresholds continue to tighten; UK Online Safety Act and EU-level age assurance duties expand the population of platforms carrying documented verification obligations.
What to put to your merchants this quarter
The useful reframing is that none of this asks you to become a content moderator. It asks you to stop accepting an unverifiable assertion as a control. Five questions separate a portfolio that will survive a review from one that will not:
- Run a retrieval drill, not a document request. Pick a live URL at random and ask the merchant to produce the complete consent chain for every identifiable person in it. Time it. Anything beyond 48 hours is a finding, regardless of what comes back.
- Ask how identity was bound to the person, not to the paperwork. Was there a biometric check against the document at the point of verification, or was an ID scan simply filed alongside a signature?
- Ask what the consent status is today. Not what was signed — what the current state is, and how the merchant would know if it had changed.
- Ask who holds the performer identity documents, where they sit, and what the breach exposure looks like. That store is an incident waiting to become your problem too.
- Ask whether the evidence is verifiable without the merchant. If the only route to confirming a record is asking the party whose compliance is in question, it is not evidence. It is a testimonial.
Where ProntoID fits
ProntoTag was built for the specific gap described above: making age and consent an independently verifiable property of an asset, rather than a claim held inside a merchant's filing system.
The mechanics are straightforward. Every person appearing in a piece of content verifies their identity directly with ProntoID — document capture, MRZ parsing and a biometric liveness check binding the living person to the document. The consent instrument is then signed against the legal name resolved from that verified document, not against text typed into a form, and recorded against the specific asset rather than against a performer profile. The merchant never receives or stores the underlying identity documents at all.
Each of the four weaknesses set out earlier is addressed directly:
- Identity is bound to a person. A liveness-checked biometric match against the document means the record evidences a verified human being of confirmed age, not a photocopy in a folder.
- Records are indexed per asset. Consent attaches to the specific piece of content and lists every person tagged in it, so the answer to “show me the chain behind this URL” is a lookup rather than an archaeology project.
- Status is queryable, not historical. Consent is a current state that can be checked at the moment it matters, and withdrawal is recorded as a new signed instrument against the original — with an authenticated notice dispatched to the platform by webhook rather than arriving as an unverifiable email from an address nobody can confirm.
- The document store disappears. Identity documents remain with ProntoID under Swiss operation and GDPR controls. The merchant holds an assertion. There is no performer ID archive in your portfolio to be breached.
For the acquiring side specifically, the property that matters most is the one implied by all four: the evidence is verifiable without asking the merchant. A processor can require ProntoTag as an onboarding condition and then satisfy itself of coverage directly, continuously, across every merchant in the book — instead of collecting attestations it has no means of testing and discovering the gaps during a scheme review.
It is worth being precise about one limit rather than overselling it. ProntoID transmits an authenticated withdrawal notice to the platform; it does not seize control of merchant infrastructure and cannot itself remove a file. What it removes is the ambiguity — whether the notice was genuine, when it arrived, which asset it concerned, and whether anyone acted. In a review, that record of receipt and response is precisely what is being asked for.
The same mechanics apply well beyond adult content. Any portfolio containing dating platforms, creator marketplaces or user-generated video carries a version of the same problem: identifiable people appear in monetised content, and somebody has to be able to prove they agreed to it. The difference is only how quickly a regulator or a scheme will ask. Get in touch if you are reviewing controls across a high-integrity-risk book, or read how ProntoTag handles per-asset consent in full.