A fraudster burned at one bank rarely stops there. They move to the next payment service provider (PSP) with a clean profile and start over.
The signals to catch them already exist. They just don't travel between institutions. That is why, under the Payment Services Regulation (PSR) – still at the proposal stage – sharing fraud data between PSPs may soon become a strict legal obligation, not a courtesy.
The FRIDA scheme (Fraud Information Distribution Arrangement) is the answer proposed by the European Payments Council's (EPC), the not-for-profit industry body that manages Europe's SEPA payment schemes. The EPC's public consultation on the FRIDA scheme is open now, and the clock to Q4 2028 has started.
What the FRIDA scheme actually is
FRIDA (Fraud Information Distribution Arrangement) is a new EPC scheme that lets PSPs share fraud alerts with one another across the Single Euro Payments Area (SEPA).
It is the EPC’s response to the proposed PSR Article 83a. This article might require financial institutions to share fraud data on account-to-account payments. FRIDA is the shared rulebook, and the shared mechanism, that makes that requirement work in practice.
At the center of it is the FRIDA Central Platform (FCP). This is planned to be a hub that receives fraud alerts, stores them, and distributes them to every connected participant. Hub and spoke, one standard, near-real-time. The point is straight-through processing: less manual back-and-forth between fraud teams, more automated signal moving where it needs to go.
The timeline is set. The consultation on Rulebook v0.1 runs from 11 September to 10 December 2026. Version 1.0 and the technical specifications are due around May and June 2027. The scheme enters effect in Q4 2028, aligned with the PSR. That sounds far off. It isn't –
not for a change that touches your transaction monitoring, your data model, and your vendor roadmap all at once.
How a fraud alert moves between PSPs
The mechanics are worth understanding, because they shape what lands in your systems.
Each fraud alert follows a clean lifecycle: it's created by the sending PSP when there are objectively justified reasons to suspect fraud. Then, it is updated as a new detail emerges – even cancelled if it turns out to be a false positive. They are removed automatically after three months. Alerts are distributed near-real-time, and participants are expected to retrieve them at least once a day – but in practice, even more often.
What travels is deliberately minimal. The mandatory dataset is small:
- an alert ID,
- a timestamp,
- a fraud category drawn from the EBA taxonomy,
- the identifier at risk (usually an IBAN),
- the account-servicing PSP, and a status.
Richer detail like transaction data, account holder information, or device signals is optional and shared only where it's relevant to the case. This is to follow the data-minimisation principle. You receive structured, traceable signal, not a data dump.
The part most teams will miss: FRIDA distributes, it doesn't decide
The data shared through FRIDA is explicitly not a stop list. Under PSR Article 83a, it may not be used as the sole basis for a customer-facing decision. It's one input into your transaction monitoring, not a verdict.
Read that carefully, because it quietly moves the work back onto you.
FRIDA solves distribution. It hands every participating PSP a wider, faster stream of fraud signal. What it does not do is tell you what any single alert means for your customer, your risk appetite, or your next action. Every inbound alert still has to be weighed inside your own framework, scored against your own rules, and turned into a decision by someone accountable for it.
Distribution is the solved part. Deciding is still yours – and that's exactly where a scheme like this either strengthens your controls or just adds noise.
What compliance teams should do before the end of 2028
Q4 2028 is three budget cycles away. The institutions that handle FRIDA well will be the ones that start shaping their framework now. Three moves matter most:
- Get your rules ready to absorb a firehose. A daily stream of external alerts is only as useful as your transaction monitoring logic that filters, scores, and prioritizes it against your own risk sensibilities
- Keep a human accountable for every judgment. FRIDA can't decide. And neither should a black box. Alerts need investigation that's automated but never unaccountable, so an analyst always owns the decision
- Make everything audit-ready by default. Every alert you act on, and every one you dismiss, should leave a clean, traceable record for reporting and dispute resolution
This is the layer Marble is built for: compliance AI that adapts to your framework instead of forcing you to adapt to it.
FRIDA will decide what signal reaches you. You decide what to do with it – on infrastructure you control, with logic you can change without waiting on an IT release. If you want to see how that works in production, the open-source core and docs are a good place to start, and our customer stories show it running at scale.
Have your say before December, then get ready
FRIDA isn't finished. Rulebook v0.1 is a draft, and the EPC wants industry input.
If your team runs fraud operations or transaction monitoring, this is the moment to shape the scheme you'll live with for years. Read the consultation and the rulebook and send the EPC your feedback before the deadline of 10 December 2026. Silence now is a rulebook written without you.
Then get your side ready.
The PSPs that come out ahead won't be the ones that receive the most alerts. They'll be the ones that decide fastest, cleanest, and on their own terms. See how Marble turns fraud signal into decisions, or book a demo.
