Why SWIFT Is Mainstream

SWIFT was originally established solely to support treasury and correspondent trading. Remittance-based messages still account for nearly 50% of traffic, but 43% are related to securities trading. The rest of the traffic is related to treasury trading. More than 15 million financial messages per day (5 billion per year) are exchanged on SWIFTNet, connecting over 11,000 global financial institutions in over 200 countries and regions.

SWIFT users

SWIFT's robust message format was so scalable that it was gradually expanded to serve the following verticals:

• Banks, brokerage firms, trading companies
• securities dealer
• Asset management company
• Clearing Houses, Depository Institutions, Exchanges
• business corporation
• Fixed income market participants and service providers
• Forex Broker, Financial Broker

SWIFT does not store funds or manage accounts on behalf of its customers, but enables secure communication for its user community around the world. By exchanging standardized financial messages in a reliable manner, it facilitates the flow of funds both domestically and internationally and underpins international commerce.

Key components of SWIFT

Figure 1: Sending and receiving secure transaction messages between a wide range of financial institutions
Enabling SWIFT infrastructure

SWIFTNet: SWIFTNet provides a generic interface to all networked and participating financial institution applications. Access is controlled by the business policy decisions of each service administrator, not by technical infrastructure constraints.

SWIFTNet Link: Business applications access SWIFTNet services using the SWIFTNet Link (SNL) API on all external interfaces. Its background processes support messaging, security, and service management functions. It is built into SWIFTAlliance WebStation and SWIFTAlliance Gateway.

SWIFTAlliance Gateway: The SWIFTAlliance Gateway (SAG) allows business applications running on heterogeneous computing platforms to send messages over SWIFTNet. Messages are received through a host adapter, such as the WebSphere MQ host adapter.

Figure 2: Alliance Messaging Hub architecture overview

Alliance Messaging Hub: Alliance Messaging Hub (AMH) supports customers' business operations by handling messages to multiple global networks. Scalable and customizable, AMH provides routing between various messaging services and supports several integrations. Technical staff can create their own business flows, transformations, report definitions and complex business routings.

SWIFT message flow

Preparing a SWIFT message (FIN) consists of the following steps:

• Message Compose: Users access a message compose application to compose SWIFT messages. Each message is processed according to its type and format, as well as authority and routing defined by the financial institution.

• Message Validation: The Message Validation application validates important fields of SWIFT FIN messages such as date of delivery, currency and amount. In most cases, message authors do not validate messages. Instead, the verifier re-enters values for those critical fields that appear blank. If the field sets do not match, message validation will not succeed. Messages awaiting verification are held in the message verification queue (_MP_verification).

• Message Approval: Verified SWIFT FIN messages and system messages approve for sending with the Message Approval application. A visual check is performed at this time. An approval message held in the message approval queue (_MP_authorization) is normally approved by a supervisor. Approval causes the message to be transmitted to the network queue specified in the message. Alliance Access automatically forwards messages from network queues.

Control loopholes and known SWIFT fraud issues

A large bank reported loopholes in SWIFT trading in two case studies below.

In the first case, the financial institution did not establish dual control processes for creating, validating, authorizing, and sending free-format messages validating confirmer-creator transactions. As a result, a series of SWIFT messages regarding modification of remittance orders exchanged between financial institutions and their correspondent banks were not forwarded for review by supervisors.

An investigation found that the supervisor had neglected due diligence prior to approving loan disbursements due to staffing shortages. Due to insufficient control over the receipt and delivery of inbound SWIFT messages, a bank clerk exploited a loophole to re-invoke the loan process and transfer money to his personal account.

Another recent case involved abuse of the transaction verification process. The process consists of three steps: an author enters a SWIFT message into the system, a verifier checks it, and a verifier verifies its authenticity before sending it out. But here fraud is made possible by the collusion (performed in this case by the same person) of three or more of the authors, confirmers, verifiers, and recipients of the message confirming the creation of the loan. I was.

Key Detection Use Cases by Financial Institutions

• Few financial institutions seek and are able to detect anomalous relationships between those in the SWIFT message creator role and those in the confirmer role. Research has shown that fraudulent transactions can occur when certain reviewers are the most frequent approvers for associated message creators.
• FIN message approvers should be separate from message authors or message verifiers. Suspicious transactions can be detected when a FIN message is created and approved or approved and verified from the same device or by the same person.
• Authors and reviewers typically perform FIN message activities during normal business hours from their preferred devices. You can detect fraudulent activity by monitoring unusual login activity for authors and reviewers.

How Exabeam Advanced Analytics Prevents SWIFT Fraud

Exabeam Advanced Analytics uses machine learning and behavioral analytics to create user and device baselines to detect anomalous activity. Ingest logs from Windows Active Directory (AD), proxies, firewalls, security alerts, databases and other applications.

Based on our latest deployment, at least 7 event types can be captured from SWIFT Alliance Gateway logs. Three of them are related to SWIFT messages (message creation, validation, approval) and four to login activity.

Figure 3: SWIFT events created in Exabeam Advanced Analytics

How it works: When Exabeam Advanced Analytics receives Alliance Gateway logs, it parses and normalizes them to create events corresponding to specific SWIFT-related activities, as shown in Figure 3.

Figure 4: Advanced Analytics user session showing application events

A session timeline is created using machine learning and behavioral analytics to create a baseline of activity for each user and device. As shown in Figure 4, SWIFT-related events are stitched into the user's timeline along with other events from other environmental logs (Windows, proxy, email, printers, etc.).

Figure 5: Advanced Analytics display of learned behavioral models related to user's application activity

Behavioral models can learn various criteria from Alliance Gateway logs (Fig. 5) as follows:

• FIN message types handled by each user and their department
• Hours of the week during which SWIFT messages were processed
• Devices typically used by each SWIFT user
• Advanced Analytics uses a risk engine to detect anomalous SWIFT activity from learned behavioral models and established risk rules. For example:
• If a message creator uses a particular approver frequently, an alert will be raised when SWIFT message approval takes place between them. How it works: Behavioral models allow Advanced Analytics to learn message creators for specific approvers and approvers for specific verifiers. Advanced Analytics will alert you if authors use approvers frequently (>30%). Similar models and rules can be created for approvers and verifiers.

Other detection rule examples include:

• Alert if author and reviewer (validator or approver) are on the same machine.
• An alert occurs when the creator and approver are the same user.
• Alert when FIN messages are created during unusual hours.
• Alert when a FIN message is created for an unusual country.
• Alert when FIN message creation occurs on a device that has never been associated with the creator.

Detecting unusual and unauthorized activity in SWIFT and similar applications

The example below shows how Exabeam can detect anomalous and high-risk activity in financial applications.

Figure 6: User's learned normal behavior

First, Exabeam creates a baseline of normal user behavior. Using machine learning and behavioral modeling, Advanced Analytics learns the application activity types of all users in your organization (Figure 6).

Figure 7: Excessive and anomalous application object accesses or transactions

By learning more about behavioral models for activities such as accessing application objects, in Figure 7 Advanced Analytics' risk engine detected anomalous activity for users accessing over 300 application objects.

Figure 8: Detection of anomalous activity by Peer Group Comparison in Advanced Analytics

Figure 8 shows how anomalous activity is detected based on peer group comparison.

Figure 9: Tracking user access that occurs at unusual times with Advanced Analytics

In Figure 9, Exabeam tracks a user's access while on vacation to detect suspicious activity.

Figure 10: Advanced Analytics evaluates every activity and assigns a risk score and generates alerts for the scores based on pre-defined thresholds

Here, Advanced Analytics assigns risk scores based on normal conditions, peer group comparisons, and abnormal behavior.

Summary

By using Exabeam UEBA to detect anomalous and anomalous activity, financial institutions can analyze SWIFT logs alongside other infrastructure logs. This enables rapid detection of SWIFT events, correlation of SWIFT events with other infrastructure-related incidents, and complete visibility. Even more detailed detection is possible by creating additional behavior models and rules using several pre-made detection methods.

Harjith Prabhakaran
Senior Sales Engineer, Exabeam, Inc.