Scam Detect is intended to be used by a specific financial institution (FI), or processor offering services to a number of FIs, to assess scam risk at the level of an individual payment. This solution has been primarily designed to risk assess real-time payments inbound to and outbound from an account at the FI or processor. For outbound payments Scam Detect is positioned as the last step before the FI sends a payment through the applicable rails to the payee's FI. Any other checks done by the FI (e.g. policy checks) should be done by the FI prior to sending the payment message to Scam Detect, with only approved payments being sent to Scam Detect.

An example, for an FI working with Featurespace processing faster outbound payments via a real-time payment (RTP) system, can be found below.

sequenceDiagram
    participant P as Payer
    participant N as Payer FI/Processor
    participant A as Scam Detect
    participant R as RTP
    participant E as Payee FI/Processor
    P->>N: Payment Initiated
    N->>N: Policy Checks
    N->>A: Request to Scam Detect
    A->>N: Scam Detect Response
    N->>R: Payment Request
    R->>E: Payment Request
    E->>R: Payment Response
    R->>N: Payment Response
    R->>E: Payee FI/Processor's confirmation

For inbound payments, Scam Detect would be called when the payment request is received by the payee FIs/processor, as shown in the diagram below.

sequenceDiagram
    participant N as Payer FI/Processor
    participant R as RTP
    participant E as Payee FI/Processor
    participant A as Scam Detect
    N->>R: Payment Request
    R->>E: Payment Request
    E->>A: Request to Scam Detect
    A->>E: Scam Detect Response
    E->>R: Payment Response
    R->>E: Payee FI/Processor's confirmation

This section describes the event types that are included within Scam Detect. Scam Detect uses a single monetary event type (paymentRT) to represent different types of payments to be assessed for scam. All payment events sent to Scam Detect will receive a synchronous response.

The table below lists the two event types which are required by Scam Detect along with a description of their intended use:

The following table explains the key attributes within Scam Detect that identify the scenario that the event is representing.

A number of different parties are involved in making a payment. The following table explains, from the perspective of a payment outbound from an account at the FI integrating Scam Detect, who those parties are and how that is represented in the Scam Detect Schema

For an inbound payment (e.g. someone getting paid their salary), the accountId, accountBranchId and accountAgentId should still represent the individual registered with the FI sending the event to Scam Detect, who, in the case of an inbound payment, will be the beneficiary. Therefore, in the case of an inbound payment, the counterpartyId, counterpartyBranchId, and the counterpartyAgentId represent the payer. For more details please look at the On-us and Inbound Payments Section.

The section describes how to use the events and steering fields described in previous sections to represent specific scenarios.

Outbound Payment

Below we describe the process for sending a payment to Scam Detect and Scam Detect returning real-time response for that payment. Note that in all cases it is the FI/Processor's responsibility to use that response to make the appropriate decision to accept, hold, or decline the payment within their payment engine.

Example

• Alice sends Bob some money for his birthday via bank transfer. Alice's bank, Bank of Alice, offers real-time payments. This outbound real-time payment (paymentRT) event undergoes all of Bank of Alice's internal policy checks. Additionally, the payment may undergo additional checks from within the institution before being sent to Scam Detect.
• Alice's paymentRT message is sent to Scam Detect for risk assessment
• The scam detect score is low and so when the FI combines that with their existing risk strategy they decide to approve the payment, and it is sent through the relevant rails
• Bob receives Alice's payment in real-time (not shown below).

Note that no additional completion or declined message is required to be sent to the Scam Detect.

sequenceDiagram
    participant S as Payer FI/Processor's Payment Engine
    participant A as Scam Detect
    participant R as Real-Time Payment System (RTP)
    S->>S: Internal Policy Checks
    S->>A: Scam Detect Formatted Payment Event
    Note right of S:{ ... <br> "eventType":"paymentRT", <br> "msgStatus":"New", <br> "direction": "outbound", <br> ... }
    A->>S: Scam Detect response
    S->>R: Payment Message

Inbound payments are dealt in a similar way; when considering the same scenario above, the processing flow would look as follows:

Example

• Alice sends Bob some money for his birthday via bank transfer. Both Alice's and Bob's banks participate in the real time payment network. This inbound real-time payment (paymentRT) is received by Bob's bank from the RTP system.
• Bob's inbound paymentRT message is sent to Scam Detect for risk assessment
• The scam detect score is high and, combined with existing information, leads to Bank of Bob freezing Bob's account.

sequenceDiagram
    participant R as Real-Time Payment System (RTP)
    participant S as Payee FI/Processor's Payment Engine
    participant A as Scam Detect
    R->>S: Payment Message
    S->>A: Scam Detect Formatted Payment Event
    Note right of S:{ ... <br> "eventType":"paymentRT", <br> "msgStatus":"New", <br> "direction": "inbound", <br> ... }
    A->>S: Scam Detect response

Scam confirmations are of critical importance for the correct functioning of Scam Detect analytics; this can also include confirmation of fraudulent cases (e.g. account take over) but these won't be included in the performance reporting. Scam Detect requires fraud and scam confirmations to be sent for both fraud/scams reported by customers on payments that are let through and payments that are blocked before leaving the FI/Processor and later confirmed as fraud/scam. We expect transactionReturn events to be sent at least once a day in batch and no later than 48 hours after they were reported.

An event must be sent in for each instance of confirmed fraud. The confirmedRisk attribute must be set to "true". The originalTransactionId field in the transactionReturn event must also match the transactionId field of the corresponding payment event. Similarly, the originalTransactionDirection attribute must match the direction of the original payments that the fraud report relates to. The returnType attribute should indicate whether this is reporting a Fraud or a Scam.
The returnSubType field shall be used to provide more granularity around the type of scam; we recommend using one of the following values: advance fee scam, investment scam, invoice and mandate scam, phising/smishing, purchase scam, romance scam, vishing, and other.

Example:

• In this example, Sandy has been the victim of a scam. He then contacts Bank X to report it.
• After the bank has confirmed this is a scam, a transactionReturn message is sent to ARIC.

sequenceDiagram
    participant S as Fraud Operations
    participant A as Scam Detect
    rect rgba(244, 244, 244)
        S->>A: Fraud
        Note right of S:{ ... <br> "eventType":"transactionReturn" , <br> "confirmedRisk": true, <br> "originalTransactionDirection": "outbound", <br> "returnType": "Scam", <br>"returnSubType": "purchase scam", <br>... }
    end

This section describes how to deal with inbound payments for On-us payments.

On-us payments are where both the payer and the payee are banking with the same FI/Processor; in other words, the payment is issued and received by the same bank or credit union.

If both inbound and outbound payments are in scope for processing by Scam Detect, two different events should be sent per on-us payment for profiles to be fully updated; this is because account and counterparty are two different entity types and states are not shared between the two.

Example

• Alice sends Bob some money for his birthday via bank transfer. Alice and Bob are banking with Bank of Alice.This outbound real-time payment (paymentRT) event undergoes all of Bank of Alice's internal policy checks. Additionally, the payment may undergo additional checks from within the institution before being sent to Scam Detect.
• Alice's outbound paymentRT message is sent to Scam Detect for risk assessment
• Additionally, Bob's inbound paymentRT message is also sent to Scam Detect for risk assessment
• The scam detect score is low and so when the FI combines that with their existing risk strategy they decide to approve the payment, and the payment is settled internally
• Bob receives Alice's payment in real-time (not shown below).

For this single payment between Bob and Alice, both the inbound and the outbound messages must be sent to ARIC Risk Hub for processing.

sequenceDiagram
    participant S as Payer FI/Processor's Payment Engine
    participant A as Scam Detect
    S->>S: Internal Policy Checks
    S->>A: Scam Detect Formatted Payment Event
    Note right of S:{ ... <br> "eventType":"paymentRT", <br> "msgStatus":"New", <br>"accountId": "AlicesAccountId", <br>"counterpartyId":"BobsAccountId", <br>"direction": "outbound", <br>  ... }
    A->>S: Scam Detect response
    S->>A: Scam Detect Formatted Payment Event
    Note right of S:{ ... <br> "eventType":"paymentRT", <br> "msgStatus":"New", <br>"accountId": "BobsAccountId", <br>"counterpartyId": "AlicesAccountId"<br> "direction": "inbound", <br> ... }
    A->>S: Scam Detect response

If the system is only processing outbound payments, only send a single event per payment for processing.

In case fraud or scam was reported, two transactionReturn events should be sent.

Events