Mastercard AN 5196 and Visa VIRP

AN 5196 and VIRP are card-network requirements, not laws. In day-to-day terms they are what decides whether you keep the ability to take payments.

What they require#

Mastercard's AN 5196 and Visa's Integrity Risk Program overlap heavily, so the obligations are worth stating once:

• Documented, signed performer consent before publication. Age and identity verification alone are not consent; the networks want a signed release for the specific content.
• A removal path anyone depicted can use without an account. Public, findable, and not gated behind being a customer.
• Defined response deadlines for removal requests, with records of whether they were met.
• Periodic reporting to your acquirer on complaints, removals, and moderation activity, even in months where nothing happened.

The two programmes differ mainly in structure: AN 5196 is a Mastercard rule set applied through your acquirer, while VIRP is Visa's tiered oversight programme, and the depth of review your acquirer applies steps up with your tier. What your own acquirer asks for is set by them; the obligations above are the common floor.

Why these bite first#

A federal 2257 inspection is rare. A processor review is routine, and a processor acts on a card-network gap by suspending or terminating the merchant account. That is the practical order of risk: the networks move first, through the acquirer, on paperwork gaps.

Meeting these is not the same as meeting § 2257. The federal law wants records held and producible; the networks want consent, a removal path, deadlines, and reporting. You need both, and neither substitutes for the other.

How Easy2257 meets each one#

• Consent: a scene cannot be closed out while any performer lacks a signed model release. This is the one check that cannot be overridden, and a revoked release blocks exactly as a missing one does.
• The removal path: the public portal, no account required, described in removals and takedowns.
• Deadlines: set automatically per request (48 hours, 72 hours, or 7 business days by basis), with warnings before they expire and escalation when they pass. Same article.
• Reporting: the monthly acquirer report, below.

Your monthly acquirer report#

On the 2nd of each month, a report for the previous calendar month is generated for every account with an active subscription. You get an email when it is ready, and every report stays available under Acquirer Reports in the compliance section.

Each report counts seven things for the month: removal requests received, removal requests actioned, deadline breaches, model releases signed, scenes finalized, new ID verifications, and content log entries added. It is produced as a PDF you can forward and a JSON version for anyone who wants the data, and each file's SHA-256 digest is recorded when the report is generated and shown next to it, so a recipient can verify the file they received is the file that was produced.

A month in which nothing happened still produces a report, watermarked as a nil report. That is deliberate: an explicit "nothing occurred" statement is materially different from silence, and your acquirer expects to receive it either way.

Two things the report is not: it is not sent to your acquirer for you, and it is not editable. You forward it; the record of what was generated stays as generated.

Reading one: the summary counts tell the story. Releases signed, scenes finalized and verifications tracking your actual output is a healthy month. Removal requests are not themselves a problem, provided the actioned count keeps pace and the breach count is zero. A non-zero breach count is the line that draws questions, because it is the one that describes your conduct rather than other people's requests.

If your acquirer has already contacted you#

Work the list in this order:

1. Download your most recent acquirer reports and forward them. For most inquiries this is the whole answer.
2. If they ask for underlying records, generate the archive and provide it. It contains the signed releases, the verification records, and the digests to prove none of it moved.
3. If they ask for something in a different format, ask them to specify it against what the report and archive already contain; the data is the same.

Answer inside their stated window even if the answer is "the full archive is being generated". Silence is what escalates processor reviews, not questions.