What Data Does a FRIDA Fraud Alert Contain?
Shared fraud data can sound like full transaction histories and customer profiles moving between institutions.
The FRIDA data model is much narrower.
At its core, the FRIDA fraud alert data in the draft FRIDA Rulebook says one thing: this account, at this PSP, is suspected of this type of fraud. Everything else is optional.
Knowing exactly where that line sits is the first step in any FRIDA integration. It is also central to your data protection assessment. If you are new to the scheme, start with what FRIDA is and how it works.
Is every FRIDA field permitted under the PSR?
Yes. The rulebook states that every element of the alert is a data item listed as permitted for sharing under Article 83a of the proposed Payment Services Regulation. Sharing must still respect the GDPR, which is why the rulebook stresses data minimisation.
What Are the FRIDA Mandatory Data Attributes?
Inside a FRIDA fraud alert: the mandatory core surrounded by optional data groups
The rulebook splits each alert into two layers. The mandatory core must be supported by every participant. The optional elements are allowed under PSR Article 83a, but each PSP decides whether to use them.
Dataset DS-01, used to create an alert, sets out the mandatory core:
| Field | What it holds |
| Request ID | A unique ID for each message sent to the platform |
| Alert ID | A unique, permanent ID for the alert |
| Creation Time Stamp | When the alert was created, to the millisecond |
| Fraud Taxonomy | The type of fraud, per the EBA Fraud Taxonomy |
| Sending PSP | The BIC of the PSP creating the alert |
| Unique Identifier | The suspect account, usually an IBAN |
| Identifier Type | IBAN, BBAN, Direct Debit Creditor ID or Not-defined |
| ASPSP | The PSP holding the account |
| Alert Status and Time Stamp | For example Suspicious or Confirmed Fraud |
Put simply, the core records who reported what, about which account, at which PSP, how sure they are and when.
The Alert ID never changes. That lets the platform spot duplicates when the same alert arrives by more than one route. Updates to an alert (dataset DS-02) use the same attributes as creation.
When Is Additional Identifier Information Required?
One field is conditional, and it matters to any PSP that holds accounts on behalf of others.
Sometimes an IBAN alone is not enough to find the real customer. The ASPSP’s entry in the EPC Directory Service can flag this. When it does, the Sending PSP must add extra detail, copied from the remittance information of the payment that triggered the alert.
This is how FRIDA handles sub-accounts held for customers of e-money institutions and payment initiation providers. Our guide to FRIDA roles explains the directory and the ASPSP in more detail.
What Optional Data Can Be Shared in a FRIDA Fraud Alert?
Beyond the core, the rulebook defines several optional groups.
The transaction date is the most important. A PSP can also share the account holder’s name and country. There is a wide set of transaction data, from references and amounts to payer and payee details. And there is session data, such as the IP address and device ID.
Finally, a PSP can record whether it has notified a hosting provider under the Digital Services Act, for example about a fraudulent website or advert.
The Sending PSP chooses which optional fields to include. Receiving PSPs get the full set and can ignore what they do not need.
Why does the transaction date matter so much?
Because FRIDA’s data retention is based on it. The audit trail is kept for five years from the date of the payment that triggered the alert, and local copies must be purged on that basis too. Our article on the FRIDA fraud alert lifecycle covers retention in full.
How Does FRIDA Apply Data Minimisation?
The rulebook asks Sending PSPs to share only what is relevant to the specific case. Sharing more data does not necessarily make an alert more useful.
That echoes a wider lesson from AML. As we argued in the next phase of AML, adding more signals does not on its own produce better decisions. What matters is whether the right context reaches the right people.
The platform also checks every new alert before accepting it. It will reject an alert if the sender is not a participant, or its FIP is not authorised. It will also reject duplicates, time stamps in the future, or any field in the wrong format. Every request gets a clear answer: the platform confirms the alert, or returns an error code.
Which Fields Appear After an Alert Is Created?
Two pieces of data only appear once an alert is live.
The first is the ASPSP’s verdict on the account, such as Genuine, Fraudulent, Blocked or Closed. We explain this in our guide to FRIDA. The second is a list of linked alerts, added by the platform when several alerts name the same account.
The rulebook explains why links matter. A PSP’s monitoring system needs to know when one account has attracted more than one alert.
Can a Receiving PSP refuse optional data?
It always receives the full dataset and can choose to ignore optional fields. If internal constraints or local regulation prevent it from accepting them, the rulebook says it must discard them.
What Must Every Participant Support?
Section 4.7 of the rulebook is clear. Every participant must be able to send and receive the mandatory fields, and feed the alerts it receives into its transaction monitoring. Using the optional fields stays optional. Our guide to who must join FRIDA covers the wider obligations.
In practice, that means two mapping jobs. Your own fraud cases must be turned into FRIDA alerts. And incoming alerts must be turned into something your detection rules and investigation teams can use.
Every PSP must handle the mandatory fields. Each PSP decides how far to use the optional ones.
Your fraud systems already raise alerts. TechnoXander FRIDA Fraud Gateway shares them in the FRIDA format, and brings the alerts that matter back into your detection and investigations. Book a demo to see the data flow.
About Author:
