France Payment Platform Compliance for ACPR Scope and Control Design

How to Define ACPR Scope and Core Controls#

Decide your France regulatory perimeter early, then implement only the controls you can defend with evidence. The bigger risk is usually not that you start too small. It is scaling on the wrong assumption, then discovering later that your product, tax, or reporting position does not hold.

This guide is for compliance, legal, finance, and risk owners managing contractor, seller, or creator payments across the European Union. The aim is practical: form a defensible first view of obligations, document decisions, and escalate the points that could change your position before they become launch blockers or audit issues.

For France, treat scope discipline as a control. EU VAT rules for cross-border B2C e-commerce changed on 1 July 2021, and those changes explicitly affect online sellers and marketplaces or platforms both inside and outside the EU. In some cases, a platform is treated as a deemed supplier for VAT purposes, so marketplace flow design cannot be left to late-stage interpretation.

Where the facts fit, OSS gives you a concrete administrative path. It is optional, but it allows registration in one Member State of identification for covered cross-border VAT declaration and payment. If you opt in, you must report all supplies covered by that scheme through OSS. OSS returns also sit alongside regular VAT returns.

For complex cross-border VAT fact patterns, escalate early through a VAT Cross-border Ruling request in the participating EU country where the taxable person is VAT-registered. That is the safer path when your commercial flow is clear enough to frame a precise question but not clear enough to rely on informal interpretation.

Keep one boundary explicit from the start: these excerpts do not, by themselves, determine payment-licensing, AML, or card-authentication obligations. Confirm OSS lock-in implications up front as well. In some Union-scheme cases, the Member State of identification cannot be changed unless establishment conditions change. In certain Union-scheme cases, that choice can bind the decision year plus the next two calendar years.

Start With the Regulatory Perimeter Before Product Scoping#

Set the regulatory perimeter first, then scope product decisions inside it.

Use a simple three-layer check before features are locked: the EU legislative framework, French domestic rules including the Code monétaire et financier (CMF), and the relevant supervisory layer including ACPR. Keep those layers separate in your working memo so teams do not collapse legal source, local implementation, and supervision into one assumption.

Use labels carefully before you use them in decks#

Treat labels like Payment Service Provider (PSP), Payment Institution (PI), and Electronic Money Institution (EMI) as terms that need explicit legal confirmation in your France perimeter memo. If someone says "we are basically a PSP," pin down the exact activity, which entity performs it, and which regulatory layer the team is relying on.

This is where expensive rework starts. Once product, sales, and finance use the same label for different roles, your perimeter file stops being reliable. Everything after that inherits the confusion.

Run a first-pass perimeter test on the actual flow#

Before feature scoping, document the actual flow and answer three factual questions:

These questions do not decide authorization outcomes on their own. They give legal and compliance the minimum facts needed to assess the model, including potential authorization and cross-border passporting workstreams. If answers differ by team, reconcile the flow first and pause new scope.

Keep a dated perimeter record with the transaction map, entities involved, contracts in scope, and open assumptions. If the supervisory view is later tested, this evidence is what protects decision quality.

Freeze the features that change your perimeter fastest#

If the design is still moving, freeze the features most likely to shift perimeter classification until legal and compliance sign off in writing. In cross-border operations, overlapping or conflicting obligations across jurisdictions can increase cost and uncertainty, so avoid building ahead of an unresolved perimeter.

Use a hard rule: no high-risk payment-flow change moves to build until written sign-off names the entities, rule layers reviewed, open questions, and revisit conditions.

For control ownership and escalation design, see How to Build a Compliance Operations Team for a Scaling Payment Platform.

Who Regulates What in France and When to Escalate#

Once your perimeter draft is on paper, build a working regulator map and use it to decide when to stop debating internally. Teams may start by mapping ACPR, TRACFIN, and AMF touchpoints, but the sources here do not confirm exact role boundaries for this platform model, so the perimeter still has to be validated case by case.

Apply a hard internal escalation rule: if a model change could alter your licensing analysis or AML reporting process, pause rollout and route it to counsel and a named regulator-facing owner. Typical triggers include changes to outsourcing arrangements, customer due diligence controls, governance ownership, and transaction-monitoring or reporting workflows.

This is a risk-control decision, not a formality. EU supervisors reported that 70% of competent authorities see high or increasing ML/TF risk in FinTech, with recurring weaknesses in outsourcing oversight, cybercrime exposure, customer due diligence, and governance. EuReCA submissions also point to serious compliance failures.

Keep the trigger list short enough that teams actually use it:

• A new entity or outsourcing change affects who performs oversight, monitoring, or control checks.
• AML alert rules, case-closing criteria, onboarding evidence requirements, or transaction-to-identity reconciliation processes change in ways that could affect suspicious-pattern reporting judgments.
• A product expansion changes the risk profile faster than governance, expertise, or controls are updated.

Keep a regulator-contact log as an internal control, even if no rule text gives you a template. Track the question, the working interpretation, the owner, the date, the fact pattern shared, and the control or document change made after review.

Before any material release, reconcile that log against your perimeter memo, AML procedures, and live controls. If legal or compliance advice changed but policy, training, or alert settings did not, treat that as an open governance gap.

For a step-by-step walkthrough, see How to Build a Payment Compliance Training Program for Your Platform Operations Team.

Do You Need ACPR Authorization or Can You Use a Partner PSP#

This is a perimeter choice before it is an operating model choice. If your entity performs core payment execution or funds-flow functions, assess whether that places you in a supervised perimeter. If a licensed provider performs that activity, document what still stays with you. Do not treat partner sponsorship as a substitute for perimeter analysis.

Direct authorization can increase control, but it also increases governance workload. The EU framework allows non-bank models alongside credit institutions: PIs provide payment services, and EMIs may issue and manage e-money and provide payment services.

The partner route appears common in market guides, but it does not remove your need to define residual obligations. Keep explicit ownership for items like customer disclosures, escalations, complaints handling, data sharing, and evidence retention.

Use ACPR's supervised-versus-unsupervised entity map as a checkpoint artifact before launch. If your architecture, terms, or settlement flow show your entity doing more than a software or commercial role, pause and re-test the perimeter with counsel.

Perimeter exceptions may exist under local PSD2 implementation, but they are fact-specific. Do not rely on labels alone. Tie any exception position to your exact operating facts in writing.

Before go-live, consider a written go/no-go memo signed by legal, compliance, and finance as an internal control. It should state the chosen model, assumptions, partner role if any, and day-one controls.

Related reading: Build a Global Contractor Payment Compliance Calendar for Monthly, Quarterly, and Annual Obligations.

Build the Minimum Defensible AML Control Stack#

Start smaller than your ambition and stronger than your policy deck. Build an AML control stack you can evidence end to end, and treat legal thresholds as a separate confirmation track with counsel. This section is about durable records and audit-ready traceability, not a France-specific filing checklist.

Start with a control map that assigns one owner, one decision point, and one evidence artifact per control label.

Use EU legal labels as a change log, not as operating proof. If you track items such as AML4, AML5, AMLR, and AMLD6, link each label to a concrete internal control and stored evidence. Also mark any item still pending legal confirmation.

Keep the operating sequence fixed: onboarding review, risk scoring, monitoring, alert triage, escalation decision, and retention. When that sequence breaks, your evidence set fragments and decisions become hard to defend.

For auditability, apply the same discipline seen in EU OSS operations. Record-keeping and audit coverage are explicit there, and platforms can still have record-keeping duties even when they are not the deemed supplier. Use that as your minimum standard for evidence hygiene when a partner PSP performs part of the flow.

Run recurring internal checkpoints, then tune narrowly when one fails. Review alert quality, track escalation timeliness, and test whether a third party can reconstruct a decision from the record without asking the original analyst.

Design Reporting and Case Escalation That Survives Audit#

If you want your escalation process to survive audit, separate investigation from final filing decisions, use one reconstructible case-file format, and review closed cases on a recurring cadence.

Treat the internal path to a possible external filing as a governed decision chain, not an ad hoc handoff. Front-line ops can investigate and assemble facts, while a designated compliance authority makes final filing decisions, with legal and executive input routed through defined lanes when needed.

Set three clear escalation lanes#

If a case touches more than one lane, assign one lead owner and one final decision record.

Standardize the case file before volume forces shortcuts#

Do this before volume makes inconsistency normal. Use one template for every escalated case, including "close, no filing" outcomes. At minimum, capture:

• Event timeline
• Customer profile
• Triggered rule
• Analyst reasoning
• Decision timestamp
• Linked internal policy reference used for the decision

Also store the rule or scenario version, reviewed support, relevant transaction snapshots, prior alert history, and the named approver so a second reviewer can reach the same conclusion from the file alone.

Put a rhythm around closed-case learning#

Closed-case review is where weak reasoning usually shows up. Set a recurring review cadence, for example weekly case review and monthly thematic analysis, as governance controls rather than legal shortcuts. Weekly review can check recent escalations, reversals, aging cases, and thin rationales. Monthly analysis can group similar cases to spot repeat typologies and inconsistent outcomes.

The same principle shows up elsewhere: recurring monitoring depends on reporting structures. The AMI-SeCo exercise is annual, the 2024 cycle was the fifth run by CEG, and the report flags missing reporting structures as a participation risk. Use the same idea internally so review meetings stay evidence-based.

Set Anti-Fraud Rules for SCA and 3DS Without Breaking Conversion#

Do not let fraud tooling make the checkout decision for you. Set one explicit rule for card payments in PSD2 scope. Decide when to run Strong Customer Authentication (SCA) with EMV 3DS, when to request an exemption, and when to require re-authentication instead of blind retries.

Start with scope, not with fraud tooling#

Do not trigger 3DS on every payment by default. PSD2 scope is conditional: for card e-commerce, it applies when both the issuer and acquirer are in the EEA. If your acquirer is outside the EEA, PSD2 does not apply to that flow.

For in-scope e-commerce card payments, SCA requires 2 of 3 factor types, and EMV 3DS is the card-authentication path. Make that a clear product decision point, then log the decision trail: in-scope status, whether 3DS ran, whether an exemption was requested at authentication or payment request, and the issuer response.

Make transaction origin explicit#

Label transaction origin at creation and preserve it through retries and investigations, including whether a payment is MOTO. The goal is traceability, so retries and support actions do not silently change the flow type.

Use MOTO carefully. It is listed as a category that does not require SCA under PSD2, so reserve it for genuine mail or telephone order handling rather than as a workaround for digital checkout issues.

A practical control is to sample declines and retries and confirm the origin label, 3DS status, exemption request, and final issuer response still reconcile across logs and case files.

Tune for approval rate carefully#

Assume a real tradeoff, not a one-way effect. 3DS can add 1 additional checkout step and increase abandonment risk, but outcomes depend on implementation and issuer handling, and some journeys can remain smooth.

If fraud controls materially reduce approvals or completed checkouts, tune routing and exemptions only with documented risk acceptance. Record the flow changed, expected conversion impact, fraud-loss tradeoff, liability impact, approver, and review date.

Keep exemption behavior explicit in your rules as well. A requested acquirer exemption is not guaranteed because the issuer may accept or decline it. Liability also differs by path, for example issuer-applied exemption versus issuer-granted requested acquirer exemption. For France-specific treatment, assume gaps in this section and validate tuning decisions against your own issuer-response data before rollout.

Handle Recurring and Exception Flows Without Hidden Compliance Debt#

Recurring and exception flows are where hidden compliance debt can build quickly. Treat them as an internal-control problem first. Document the payment chain so you can defend classification decisions under PSD2 (Directive (EU) 2015/2366) and the SCA framework in Commission Delegated Regulation (EU) 2018/389.

For MIT integrity, keep an auditable trail that links each later charge to the original customer action. Capture and retain relevant evidence, for example consent records, transaction references, origin labels, timestamps, and processor records, based on your control design. The goal is not to claim a perfect template; it is to retain evidence that explains why the flow was handled that way.

For exceptions, define and document internal rules before volume creates drift. If a processor or issuer later declines a previously accepted recurring charge, reconcile processor outcome, internal ledger state, and customer account status before irreversible downstream steps. The provided materials do not set detailed notification or fallback re-authentication timing rules, so treat those as explicit policy choices and record them.

Keep the control set strict:

• No undocumented workaround around authentication controls.
• No relabeling of digital flows to lower-friction categories just to recover approvals.
• No downstream release until processor status, ledger entries, and payout calculations match.

Use a quarterly checkpoint on recurring failures and manual overrides. Review timeline integrity, origin labels, authentication path, decline handling, and ledger corrections, then retain that evidence in line with internal-control reporting expectations.

Related: Music Royalty Tax Compliance: How Platforms Handle 1099-MISC vs. 1099-NEC for Artist Payments.

Define Control Ownership Across Legal Risk Finance and Engineering#

If ownership is fuzzy, your controls will look adequate on paper and fail under pressure. Define control ownership in writing before incidents force ad hoc decisions. The goal is not to mirror a regulator-prescribed org chart. It is to show how your team measures, monitors, manages, and discloses risk with enough detail that a reviewer can follow how controls work in practice.

Put names on control domains#

Use a simple ownership map with one accountable owner, a backup, and a documented exception path per control domain. The excerpts do not prescribe a fixed role split, so define yours explicitly, for example:

Keep a current decision trail for each control, including owner, rationale, date, and scope.

Make decision rights unambiguous#

Set decision rights in advance for material control changes and temporary exceptions. If those rights live only in chat or ticket comments, they are hard to defend during audit or incident review.

Tie decisions to governance artifacts you can produce. ACPR internal-control materials point to risk-exposure reporting from effective managers to the supervisory body under Article 253 of the Arrêté du 3 novembre 2014. That sits within a broader reporting basis in Articles 258 to 266. If your documentation cannot roll up into that reporting layer, ownership is still too informal.

Minimum evidence for a material change:

• owner and approver names
• scope and effective date
• risk assessment and review evidence
• expiry and follow-up for temporary exceptions, if used

Give engineering controls an evidence purpose#

Engineering controls should make internal-control evidence retrievable without custom reconstruction every time. In practice, keep records that show what changed, when, why, and who reviewed it.

Test this regularly: pick recent control decisions and confirm you can export a clear timeline with timestamps, decision owner, and review outcome. If that export fails, the control may operate, but it is weak as evidence.

For deeper logging design, see What Is an Audit Trail? How Payment Platforms Build Tamper-Proof Transaction Logs for Compliance.

Add a real cross-functional change gate#

For material changes, use a formal cross-functional gate with documented review across legal, compliance, risk, finance, and engineering.

Do not rely on AMF summary material alone for binding interpretation. AMF states some information boxes are informational only and not regulatory instruments, and it does not guarantee complete redirections to EU texts. Verify primary legal sources before approval.

For material changes, make sure the outcome can be reflected in internal management risk reports reviewed by the supervisory body, with preserved meeting records. ACPR materials also reference sending reviewed documents and meeting-minute extracts to SGACPR under Article 4 of Instruction No 2017-I24.

For evidence design around approvals, changes, and traceability, see Internal Payment Audit Trail for Platform Compliance.

Assemble the Launch Evidence Pack Before You Go Live#

Before launch, you should be able to prove what you decided, why you decided it, and what you tested. Treat a complete evidence pack as a core risk control, not paperwork.

What the pack should contain#

Use this as an internal minimum launch packet, not as a claim about a jurisdiction-specific statutory checklist:

Make clause-to-control mapping explicit. If a control is claimed, you should be able to show the policy version, the product surface it covers, and the owner responsible for it.

Add test evidence, not just policy PDFs#

A launch pack full of policy PDFs is not enough. Include onboarding control tests, suspicious-alert drills, and scenario validation logs across onboarding, payment initiation or authentication, and payment execution.

Include at least one drill for third-party compromise, supply-chain attack, or IT outage. Those scenarios are explicit payment-threat cases and can expose escalation weaknesses early.

Ask for exports with timestamps, event IDs, triggered rules, analyst actions, and final case state. If evidence cannot be reproduced after testing, launch readiness is still weak.

Make sign-off traceable#

Use one internal approval packet across legal, compliance, risk, finance, and engineering owners, with version-controlled documents. Keep one dated bundle, list unresolved exceptions, and set expiry dates for temporary approvals so the launch record stays defensible.

For the customer due diligence side of the control framework, see KYC Best Practices for Reducing Money Laundering Risks: A Payment Platform Compliance Guide.

Turn this section into a launch gate: assign owners, attach evidence, and verify each control can be demonstrated in operations using the Gruv docs.

Verify Live Operations in the First 90 Days#

Go-live is not proof your controls work. The first 90 days should show, with production evidence, that you can identify, measure, monitor, and mitigate risk over time. Use a fixed cadence to detect deterioration early, then escalate when control quality drops.

Use a 30 60 90 cadence#

A 30 60 90 structure is an operating discipline, not a France-specific legal requirement.

Define trigger based escalation before you need it#

Cadence reviews matter, but they are not enough on their own. If monitoring misses a high-risk pattern, or case handling quality degrades materially, retune controls and start a leadership review.

For each escalation, keep a defensible evidence set: triggered control, impacted volume, case samples, event IDs, analyst actions, decision timestamps, and active policy or rule version. If the record cannot reconstruct what happened, treat that as a control failure, not just an alert issue.

Concentration risk also needs explicit handling. If you rely heavily on one provider, model, or external signal, have rollback plans ready so owners can tighten controls, pause risky flows, or add manual review when output quality shifts.

Check for regulatory drift#

Do not freeze your launch interpretation. In each cycle, compare internal interpretations against newly published regulatory and supervisory updates, then document the impact on your France perimeter, any remaining legal uncertainty, and whether control changes are required.

Close the loop with owned remediation#

Every gap needs a named owner, target date, and verification step. Require before-and-after evidence, approval history, and a post-deployment check so remediation is measurable and auditable. If a fix adds operational friction, document that tradeoff explicitly so legal, risk, finance, and engineering stay aligned.

Conclusion#

The shortest defensible sequence is still the right one: classify the perimeter first, implement the minimum control set you can actually run, and launch only when the evidence pack is complete. In practice, discipline beats volume.

Start with perimeter, because every later control depends on it. In France, the legal anchor is the Code Monétaire et Financier, and the compliance frame spans domestic rules plus EU directives and regulations. If you cannot clearly map your activity to the responsible regulated entity or partner model, treat that as a stop signal.

Once perimeter is clear, keep controls narrow, owned, and testable: identity verification, risk assessment, transaction monitoring, corporate verification with beneficial ownership disclosure, and a path to report suspicious activity to TRACFIN where your model creates that duty. Fewer controls with clear owners are stronger than broad policies no one can operate under load.

Your evidence pack should prove three things: the perimeter decision, control execution, and escalation logic. You should be able to retrieve a recent onboarding file and show the identity check, risk assessment, beneficial-ownership record for business customers, and monitoring outcome without rebuilding it by hand. The same applies to alert handling: reasoning should be visible, not only final status.

Keep scope coverage explicit. The due-diligence example in the grounding pack shows the risk of incomplete scope: excluding subsidiaries was central to the finding, and legal and financial accountability followed. Keep documents and control design current as conditions change, consistent with the underlying point that effective approaches must be kept up to date.

Run a cross-functional pre-launch review with legal, compliance, finance, risk, and engineering, and close unresolved ACPR/TRACFIN or other regulator-facing escalation points before expanding volume.

If your ACPR perimeter or regulated-partner model is still unresolved, run a scoped readiness review and confirm implementation coverage before launch through Gruv contact.