Anyone working in the financial services space understands the complex nature and wide scope of financial fraud. Fraud is now so widespread that the 2020 PwC Fraud Survey found that 47% of global companies had experienced fraud in the previous 24 months. Vast sums of money are being lost, in 13% of cases, a victim company lost over $50 million.
To help mitigate financial fraud, the SWIFT network has created a response in the form of the Customer Security Control Framework (CSCF), which is part of their Customer Security Programme (CSP). This security framework describes mandatory and advisory security controls for any financial organization that utilizes its services.
The latest version of the CSCF, v.2022, has added a new mandatory requirement “control 2.9 Transaction Business Controls”. Here, Eastnets explores what this change means for Financial Institutions (FIs) and how an FI can adhere to this latest CSCF update.
Control 2.9: Transaction Business Controls
The SWIFT Customer Security Control Framework (CSCF) is updated annually; this is in response to changes in the shifting cybersecurity landscape as well as to technological/process changes in the industry.
SWIFT CSCF control 2.9 Transaction Business Controls was originally added to the CSCF v.2021 as advisory only. Because of changes in the payments landscape, CSCF v.2022, now enforces the requirements in control 2.9, setting this control as mandatory for CSCF compliance.
The SWIFT definition of control 2.9 is to:
“Ensure outbound transaction activity (payment instructions) within the expected bounds of normal business”
The areas that this, now mandatory, control impact cover:
- messaging interface
- communication interface
- SWIFT and customer connector
SWIFT enforces the requirement for an FI to implement measures of control that provide the ability to detect, prevent, and validate a transaction within the bounds of normal business. The goal is to minimize the likelihood of outbound or inbound fraudulent payments.
CSCF Control 2.9 is based upon using a baseline of ‘normal’ activity that can then be used to spot anomalous behaviors/events. This forms the basis for business control implementation, using this baseline to implement control measures.
Implementation of these measures is not prescribed by SWIFT. However, SWIFT offers example measures across four key areas that should be considered best practices, and of importance in the attestation. These example measures include:
Limitations on transactions outside of business hours
A limit of the time allowed for SWIFT messages transactions can help to mitigate fraudulent transactions. However, this limitation may not be suitable in FIs that have cross-over business hours between business units and jurisdictions. Also, fraudsters can mix in SWIFT messages during normal business hours, so messages must always be monitored.
Limitation on a transaction basis
Rules that limit transactions can be applied to mitigate the impact of fraud, for example, place limits on transaction amounts. However, clever fraudster tactics can use multiple small amounts to circumvent such restrictions. This measure must be applied smartly to be effective.
Validation of messages
SWIFT suggests using end-of-day and/or intra-day validation of messaging to spot fraud. This measure adds bandwidth to an operator’s work and may also not find fraud until after it has occurred. Again, a smart approach to applying this measure is required.
Detection of abnormal behavior
SWIFT suggests using a baseline to check against to detect abnormal transactions that can then be stopped. With modern AI-enabled anti-fraud solutions, this method can be more impactful and effective than simpler hard-coded rules. However, using a solution that utilizes AI-enabled antifraud with traditional rules-based AML can prove effective.
How can an FI meet the requirements of 2.9 Transaction Business Controls?
The change from advisory to mandatory for control 2.9 Transaction Business Controls, means that an FI MUST meet this requirement to attest compliance. But creating business controls is an area that can impact the operations of an FI negatively unless due care in choosing a solution is taken.
Attestation to SWIFT CSCF v.2022 is on the horizon and must be done between July 2022 and December 2022. As these dates draw close, what kind of solution will meet this control, whilst minimizing the impact on FI operations?
Let’s look at the requirements and how a solution such as Eastnets PaymentGuard maps to each:
Limiting traffic outside of business hours
Any restrictions within a payment transaction have the potential to cause a negative impact somewhere along that process lifecycle. A solution that can provide these restrictions without limiting the underlying process must use a more intelligent approach than an on/off switch.
Eastnets PaymentGuard uses advanced and intelligent rules to comply with CSCF control 2.9. without interrupting existing payment workflows. PaymentGuard can differentiate between outgoing traffic timings that are source-dependent. This level of granularity is vital in a multi-national, cross-jurisdictional, FI. Eastnets PaymentGuard provides a mix of traditional rules as well as machine learning models that learn traffic timings per user, business unit, and per correspondent.
Limiting traffic beyond normal business
If a transaction goes outside the bounds of an expected range, an alert should be generated to check the transaction before they are sent to the SWIFT network.
Eastnets PaymentGuard sets transaction thresholds and aggregation rules based on transaction instructions, context, and temporal properties. These rules are used smartly, by applying the concept of the ‘reference amount’, the calculation is then based on a reference currency. Further conditions can be defined using threshold amounts against one currency that can be used as a template for other currencies. This level of granularity and sensitivity can only be achieved using artificial intelligence and statistical models that detect anomalies across the set criteria, e.g., reference amount.
Message checking and reconciliation
Matching of MT900 and MT 910 messages
One of the suggested measures of CSCF v.2022 control 29, is to use MT900 and MT910 confirmation. These messages confirm a debit by the sender's bank account as a result of executing the received transaction (e.g., MT103). Financial Institutions are required to check that the received confirmation e.g., MT900, matches its underlying payment e.g., MT103.
Eastnets PaymentGuard provides automated message matching. The AI-enabled model can also check that the underlying payment has been analyzed against the defined fraud scenarios before it was sent to the SWIFT network. Also, PaymentGuard can verify that the underlying payment exists in the back-office application of the bank.
Fraud can be detected during the reconciliation of statements as soon as they are received. This on-the-fly reconciliation gives time for the financial institution to react.
Eastnets PaymentGuard reconciles the MT940 or MT950 statements as soon as they are received against their underlying SWIFT payments. The model can also check if all entries correspond to payments that exist in the back-office application.
Control 2.9 requires that all messages sent to the SWIFT network exist in the back-office application of the bank. This prevents injected payments either directly in the SWIFT messaging Interface or via Alliance Access methods.
Eastnets PaymentGuard provides a real-time reconciliation model, called “message authenticity”. This feature validates that the message exists in the back-office application before it gets released to the SWIFT network.
Detection of abnormal behavior
The goal of CSCF control 2.9 is to detect fraudulent payments. A robust measure to achieve compliance with control 2.9 is the intelligent analysis of SWIFT messages to detect abnormalities. Variables including beneficiary amounts, timing, country, currency, correspondence, and so on, all offer insights into unusual behavior. However, because of the wide range of potential abnormal properties of a message, it can be difficult to detect this unusual behavior.
Eastnets PaymentGuard includes statistical and artificial intelligence models that are designed to detect transaction anomalies across a wide range of message elements.
Monitoring of terminal login sessions
CSCF control 2.9 requires that logical terminal login session numbers are monitored to ensure that there are no gaps in the session numbers.
Eastnets PaymentGuard provides a warning model that monitors the logical terminal session numbers and issues warnings whenever a gap is spotted.
Attest success using smart transaction analysis
SWIFT has made CSCF Control 29 mandatory because of high levels of fraudulent payments. However, this control could cause operational headaches if not implemented smartly. By using the more flexible nature of AI-enabled antifraud solutions, like PaymentGuard, an FI can ensure that it can meet the fine-grained requirements of CSCF v.2022 control 29, without harming business.
Download the factsheet addressing the new control 2.9 and further information on how PaymentsGuard can help your FI meet the new CSCF v.2022 regulation.