Detecting Anomalous Activity in Financial SWIFT Transactions With Machine Learning and Behavioral Analytics

The Society for Worldwide Interbank Financial Telecommunication (SWIFT) is a network that enables institutions to transmit financial transaction information in a secure, standardized, and reliable environment. But SWIFT fraud has been documented in banks and other institutions as a result of known system loopholes. In one case, system controls for the creation, verification, authorization, and transmission of free-format SWIFT messages weren’t implemented, resulting in a clerk being able to redirect funds.

In this post, we’ll look at how the SWIFT network works, review documented fraud use cases, and show what financial institutions can do to prevent SWIFT fraud.

Why is SWIFT dominant?

SWIFT was initially created to facilitate treasury and correspondent transactions only. Today payment-based messages still account for nearly 50 percent of its traffic, while 43 percent now concerns security transactions. The remaining traffic flows to treasury transactions. Linking more than 11,000 global financial institutions in more than 200 countries and territories, over 15 million financial messages per day (five billion messages a year) are exchanged on SWIFTNet.

Who uses SWIFT?

SWIFT’s robust message format permits huge scalability, so it has gradually expanded to provide services to the following:

• Banks, brokerage institutions, and trading houses
• Securities dealers
• Asset management companies
• Clearinghouses, depositories, and exchanges
• Corporate business houses
• Treasury market participants and service providers
• Foreign exchange and money brokers

Although it doesn’t hold funds or manage accounts on behalf of customers, SWIFT enables a global user community to communicate securely. It exchanges standardized financial messages in a reliable way, facilitating global and local financial flows, and supporting international trade and commerce.

Key SWIFT components

Figure 1: The SWIFT infrastructure provides secure transaction messaging among a wide range of financial entities.

SWIFTNet – SWIFTNet provides a general-purpose interface for all connected participating financial institution applications. Access is controlled by business policy decisions of each service administrator, not by the technical limitations of its infrastructure.

SWIFTNet Link – For all external interfaces, business applications use the SWIFTNet Link (SNL) API to access SWIFTNet services. Its background processes support messaging, security, and service management functions. It’s incorporated in SWIFTAlliance WebStation and SWIFTAlliance Gateway.

SWIFTAlliance Gateway – The SWIFTAlliance Gateway (SAG) permits business applications on disparate computing platforms to pass messages through SWIFTNet. Messages are received through host adapters, including a WebSphere MQ host adapter.

Figure 2: The high-level architecture of Alliance Messaging Hub.

Alliance Messaging Hub – The Alliance Messaging Hub (AMH) supports customers’ business activities with message processing to multiple global networks. Scalable and customizable, it offers routing between various messaging services and has several integrations. Technical staff can create their own business flows, transformations, report definitions, and intricate business routing.

SWIFT Message Flows

SWIFT message (FIN) preparation involves several steps:

1. Message Creation– Users access the Message Creation application to create SWIFT messages. Each message is processed depending on its type and format, as well as permission and routing defined by the financial institution:
   • SWIFT FIN messages must be verified, authorized, or both
   • SWIFT system messages must be authorized, but don’t have to be verified
2. Message Verification – The Message Verification application verifies key fields in SWIFT FIN messages, such as value dates, currencies, and amounts. In most cases, a message creator doesn’t verify it. Rather, the verifier re-enters the key fields, which are displayed as blanks. Fieldsets must match for the message to be verified. Messages waiting for verification are held in the Message Verification queue (_MP_verification).
3. Message Authorization – Verified SWIFT FIN and system messages are authorized for release by the Message Approval application, during which a visual check is made. Normally authorization messages being held in the Message Authorization queue (_MP_authorization) are approved by supervisors. When authorized, a message is transferred to the network queue specified within it. Alliance Access automatically transmits messages from the network queues.

Control loopholes and known SWIFT fraud issues

Based on a report from a leading bank, the following two case studies documented loopholes in SWIFT transactions.

In the first case, an institution didn’t establish a dual control process for the creation, verification, authorization, and transmission of free-format messages to verify the transaction between the checker-maker. As a result, a series of SWIFT messages between the financial institutions and its correspondent banks regarding remittance instruction amendments weren’t routed to the supervisor’s attention for review.

On investigation, the bank discovered a staffing shortage had led supervisors to skip their due diligence before approving the loan disbursements. Since controls over receipt and distribution of inbound SWIFT messages were inadequate, it turns out a clerk took advantage of the loophole by recalling loan proceeds she had subsequently transferred to her personal account.

Another recent case involved the misuse of the transaction verification process. In the three-step process, the maker keys the SWIFT message in the system, the checker checks it, and the verifier transmits it after they’re convinced of its genuineness. But here at least three persons from among the maker, checker, verifier, and receiver of the message confirming the loan creation conspired (the same person in this case) to make the fraud possible.

Key detection use cases from financial institutions

• Few financial institutions want to or can detect unusual relationships between one person acting as a SWIFT message maker and another as a checker. A study shows that fraudulent transactions may occur when a given checker becomes the most frequent authorizer for an associated message maker.
• A FIN message authorizer should differ from a message creator or verifier. Suspicious transactions can be detected if the FIN message creation and authorization, or authorization and verification, are conducted from the same terminal or by the same person.
• Makers and checkers usually perform FIN message activities from their usual terminals and during normal business hours. Through monitoring unusual login activity by the maker and checker, fraudulent activities can be detected.

How Exabeam Advanced Analytics prevents SWIFT fraud

To detect abnormal and anomalous activities, Exabeam Advanced Analytics uses machine learning and behavior analytics to create baselines for users and devices. It can ingest logs from Windows Active Directory (AD), proxies, firewalls, security alerts, databases, and other applications.

At least seven event types can be captured from SWIFT Alliance Gateway logs based on recent deployments. Three are related to SWIFT messages (message creation, verification, and authorization), while four pertain to login activities.

Figure 3: A SWIFT event created in Exabeam Advanced Analytics

How it works: Once Exabeam Advanced Analytics receives the Alliance Gateway logs, it parses, normalizes, and creates events for specific SWIFT-related activities, as shown in Figure 3.

Figure 4: A user session in Advanced Analytics revealing application events.

Session timelines are created using machine learning and behavioral analytics to create activity baselines for each user and device. As shown in Figure 4, the SWIFT-related events have been stitched to a user’s timeline, along with other events created from other environment logs (e.g., Windows, proxies, email, printers, and others).

Figure 5: Advanced Analytics shows learned behavioral models related to users’ applications activity.

Behavioral models can learn different criteria from the Alliance Gateway logs (Figure 5), such as:

• The FIN message type handled by each user and their department
• The time of the week when the SWIFT messages are handled
• The normal devices used by each SWIFT user

Through learned behavioral models and established risk rules, Advanced Analytics uses its risk engine to detect unusual or anomalous SWIFT activities. For example:

• Alert when a SWIFT message authorization occurs between a message maker who is also a top user of a specific authorizer.

How it works: The behavioral model lets Advanced Analytics learn the message creator for a specific authorizer, as well as the authorizer for a specific verifier. If the creator is the top user for an authorizer (> 30 percent) then Advanced Analytics triggers an alert. Similar models and rules can be created for the authorizer and verifier.

Other detection rule examples include:

• Alert when the maker and checker (verifier or authorizer) use the same machine.
• Alert when the maker and authorizer are the same users.
• Alert when FIN message creation occurs during an abnormal time.
• Alert when a FIN message is created for an unusual country.
• Alert when FIN message creation occurs from a terminal not previously associated with a creator.

Abnormal and fraudulent activities detected in applications similar to SWIFT

The following examples show how Exabeam detects abnormal and risky activities in financial applications.

Figure 6: Learned normal behavior for a user

First Exabeam creates a baseline for normal user behavior. Using machine learning and behavior modeling, Advanced Analytics learns the application activity type for all of an organization’s users (Figure 6).

Figure 7: Excessive, abnormal application object access/transaction

By further learning the behavioral model for activities such as application object access, Figure 7 shows the Advanced Analytics risk engine has detected an abnormal activity from a user who has accessed ~300 application objects.

Figure 8: Advanced Analytics compares peer groups to detect abnormal activities.

Figure 8 shows how abnormal activities are detected based on peer group comparison.

Figure 9: Advanced Analytics tracks user access at unusual times.

In Figure 9 Exabeam detects suspicious activity by tracking access for a user who is on block leave.

Figure 10: Advanced Analytics assesses all activity and assigns risk scores, which can generate corresponding alerts based on pre-established thresholds.

Here Advanced Analytics assigns risk scores based on normal, peer group comparison and anomalous behavior.

Conclusion

Using Exabeam UEBA to detect abnormal and anomalous activities, financial institutions can analyze SWIFT logs along with the rest of your infrastructure logs. This provides complete visibility in addition to rapid detection and correlation of SWIFT events alongside other infrastructure-related incidents. Several out-of-the-box detection methods let you create additional behavioral models and rules for more granular detection.