Scam Transaction Monitoring Schema

The Scam Transaction Monitoring data schema is a collection of definitions that establish the format of payment events and how these will be linked to their associated entities so the platform can build behavioural profiles. The schema defines the types of payment events the system can process, as well as the attributes contained within them. There are three different types of payment events that can be sent into Scam Transaction Monitoring:

• Real-time payments (paymentRT): Real-time payments receive a scam score in the synchronous Payments response

• Non-real-time payments (paymentNRT): Used for non-real-time payment decisioning and will not receive a scam score in the synchronous Payments response. However, it can be used for information purposes in the Fraud Transaction Monitoring Portal and/or generate silent alerts for further review. These events will also be risk scored if the required parameters are provided.

• Scam and fraud labels (paymentTransactionReturn): Informational events confirming that a scam or fraud has taken place

Each of these types have a corresponding REST API endpoint. You must ensure the data you share with Thredd matches the values in the endpoints.

It is expected that all end-customer payments are sent through as paymentRT or paymentNRT events for the Scam Transaction Monitoring model to be performant.

All payments share common attributes that are required for processing, as well as mandatory, recommended, and non-mandatory attributes specific to each transaction type. All attributes in the data are expected to be of a certain data type such as string, number, integer, Boolean, date-time, or an array. Additional validation may also be applied to restrict the permitted attribute to a specific set of expected values. If it is more efficient to design a bundle of data types that can be re-used as a JSON object instead of defining each multiple times across transactions, a derived type is defined (for example, type money). For more information on derived types, see Appendix A: Derived Types.

Parties Involved in a Payment

Several parties can be involved in the lifecycle of a payment. The parties that are most important to Scam Transaction Monitoring are the accounts where payments are sent from and to, the Funding Institutions (FIs), and the branches of the payer and payee.

The following table shows how these parties are represented in the Scam Transaction Monitoring schema. Account is the account belonging to your customer (whether the payer or payee), while counterparty relates to the account on the other side of the payment.

Account Fields	Counterparty Fields	Description
accountId	counterpartyId	A unique identifier for the accounts that the payment is sent from and to.
accountAgentId	counterpartyAgentId	A globally unique identifier for the FIs at which the accounts are held, usually the Bank Identification Code (BIC).
accountBranchId	counterpartyBranchId	A unique identifier for the FIs (at a more granular level than the *AgentId fields) at which the accounts are held. This is usually a sort code or routing number.

These fields are populated depending on the direction of the transaction. The account fields always represent the customer that belongs to the FI scoring data using Scam Transaction Monitoring.

Steering Fields

In the different messages there are several key attributes that describe the scenario that the message is representing. These attributes are known as steering fields and are key to getting optimum analytical performance from Scam Transaction Monitoring. These steering fields are shown in the following table:

Event	Field	Description
paymentRT	direction	Reflects the direction of the payment from the perspective of the institution. This is either inbound when account holder is the payee, or outbound when the account holder is the payer.
paymenttransactionReturn	originalPaymentDirection	Must match the direction of the original payment message.
	confirmedRisk	Should always be set to true where this is sent.
	returnType	Indicates whether this is reporting a confirmed fraud event of scam event. This is either fraud or scam. See What is a Scam? for more information on how these differ.