Preparing for a SWIFT message investigation

For five years, French bank Crédit Agricole funneled $32 billion in financial payments through its New York branch on behalf of clients in Iran, Sudan, Myanmar and Cuba in violation of U.S. regulations. Federal and state prosecutors ultimately accused the bank of conspiring to defraud the U.S. government by violating economic sanctions and, in 2015, Crédit Agricole agreed to pay $787 million to resolve the allegations, including a $385 million payment to the New York State Department of Financial Services. (See Credit Agricole to pay $787 million to resolve U.S. sanctions probe, by Karen Freifeld, Reuters, Oct. 20, 2015, and the Department of Financial Services press release.)

At the heart of the case were Crédit Agricole’s SWIFT (Society for Worldwide Interbank Financial Telecommunication) messages. SWIFT provides a global network for financial institutions and other members to send and receive information about financial transactions in a secure, reliable environment. The SWIFT network doesn’t process any transactions but rather relays these formatted messages between its member banks with instructions regarding financial transactions or other business communications.

Crédit Agricole used the SWIFT network to create “cover payments” to conceal the identities of parties involved in its illegal transactions. Branches outside the U.S. would exchange a SWIFT message to process a payment, like a wire transfer, that included the client identity, but they’d send a different kind of SWIFT message — without an identity — to the U.S. branch to convert the payment into U.S. dollars. This way the bank could access the U.S. financial system on behalf of its sanctioned clients without raising any red flags. (See the press release.)

SWIFT messages are often the most significant primary sources of information for investigators conducting forensic inquiries into possible money laundering, sanctions violations and other forms of financial malfeasance. In January 2017 alone, SWIFT sent nearly 27 million messages per day on average across more than 200 countries. But while SWIFT messages are standardized, they aren’t very user-friendly, and investigators can encounter a number of potential issues when they extract, process, store and analyze them. Knowing how to link seemingly unrelated SWIFT messages to a common transaction — as was done at Crédit Agricole — is just one challenge investigators and fraud examiners might encounter when preparing for SWIFT message investigations.

As a result, SWIFT message investigations require significant planning and preparation. Here are seven best practices you can follow to increase the efficiency and effectiveness of your inquiries.

No. 1: Map the data sources

A good first step is to plot out where the relevant SWIFT messages are stored or archived. Due to IT architecture decisions or cross-border data privacy considerations, global financial institutions often store their data in multiple locations. Some might have regional data storage hubs; others might store SWIFT data locally at small branches or back offices. Given all the possibilities, ask a bank’s IT professionals to extract and transmit the data. However, if a high level of independence is required, you might have to deploy your own data extraction teams to the various storage locations.

You might need to coordinate with third-party storage providers or banks to extract data because many financial institutions rely on these providers to house their data. Handle these communications with care because these vendors might be less than enthusiastic about giving an outside team access to their facilities.

No. 2: Assess data formats

Banks can store data in multiple formats. Some IT departments back up their data onto offsite tape cartridges or unexpected systems that require specialized restoration vendors. Many SWIFT messages are archived using text-based data formats. Others are saved in a format specific to SWIFT, like in MEAR (Message Archive) files. These file types contain embedded SWIFT messages. To access that message data, restore the MEAR file to the SWIFT platform using SWIFT Alliance Access or compatible software. If these aren’t available, data from the MEAR file must be accessed through its component files, which requires data restoration expertise.

Additionally, some institutions enrich their incoming SWIFT messages with other information before feeding them into their systems of record. For example, a bank might enrich a SWIFT message with the name of a client’s relationship manager. Some add a host of additional fields to their message records. In each case, you must decide whether it’s best to extract the enriched records, the original un-enriched SWIFT messages or both.

No. 3: Determine appropriate and secure extraction techniques

It’s important to always adhere to chain of custody and data security best practices when extracting SWIFT message data and transporting it to another location for analysis.

It might not be feasible to transfer data electronically from a bank’s network to your site. The data sets might be too large or the connections too slow to use Secure File Transfer Protocol (SFTP), a common method of transferring data between networks. Similarly, it might not be technically feasible or could pose security and data-integrity risks to email large volumes of data. Therefore, consider transferring the data to an encrypted hard drive and send that drive via courier for processing. With appropriately robust encryption, this is a reliable and secure approach that clearly demarcates events in a defensible chain of custody.

Chain of custody documentation should include: file names and data types, where the data was encrypted (at the host location or somewhere else), and data size. Recording hash values (a string of alphanumeric characters generated by an algorithm) of the extracted files can ensure that the copies taken match the originals held by the institution.

No. 4: Plan for onsite quality control

The most crucial onsite quality control procedure is searching for data gaps. A red flag is when you expect a SWIFT message but it’s missing. Check for data gaps using a customized utility that executes a daily count of SWIFT messages. If very few SWIFT messages are present on a business day, consult with the bank’s IT and operations professionals to determine why. It could be a red flag, or there could be a good reason like a system outage, a bank holiday, an emergency closure, a data backup error or perhaps it was simply an unusually slow business day. It’s not unusual for institutions to archive incoming and outgoing SWIFT messages in separate directories. Ask if this is the case and conduct spot checks or random samples to ensure that both kinds of messages are present in the data set.

No. 5: Understand data filtering issues

Analyze only those SWIFT messages that fall within the scope of the investigation as dictated by clients, prosecutors, regulators or other stakeholders. For example, SWIFT messages involving only certain countries or jurisdictions might be at issue. Or the inquiry might be limited to a specific time period. Devise a plan for isolating in-scope from out-of-scope messages.

If the scope is limited to certain jurisdictions, begin by filtering messages by location using the fifth and sixth characters of a SWIFT Bank Identifier Code (BIC) that denote the country where the SWIFT message originated or terminated.

For example, a search for sender and receiver BICs with “US” as the fifth and sixth characters will yield any messages sent to or from a party in the U.S. However, BICs can also be included in other SWIFT message fields. Although these other fields commonly contain BICs, many of them also allow the user to enter the name and address of the bank rather than the BIC. Therefore, a keyword search for U.S. terms, including cities and states, might also be needed to get a more complete data set. Be aware that not all U.S. jurisdictions will be captured by a search where “US” appears as the fifth and sixth characters of the BIC. For example, the eight-digit BIC ‘GMBKGUGU’ is the BIC of the Bank of Guam, which could also be considered a U.S. jurisdiction. Therefore, to compile a complete and reliable data set, filter for the fifth and sixth characters to augment a keyword search for countries, cities or states.

Filtering SWIFT messages by investigative scope can be tricky. Some SWIFT messages might show transactions in more than one currency, such as a foreign exchange transaction. Some messages might be related to letters of credit spanning time periods that only partially overlap a targeted date range. Consider the impact these complications can have on the investigation.

No. 6: Address the mirror message issue

Beware of duplicate messages when processing SWIFT message data for analysis. For example, a German bank might send an MT103 message (a common message variety that signifies a credit transfer) from its headquarters in Frankfurt to its New York City branch to execute a payment from one client to another. But in so doing, it’s created two copies of the same message: one stored in Frankfurt and one in New York.

Conducting data extractions at both locations would lead to duplicates in the data set. These “mirror messages” are compounded when dealing with large, global financial institutions with dozens of locations and can create a potential time-and-resource sink to weed out extraneous messages that could distort the actual number and value of the transactions at hand.

One of the best ways to manage these mirror messages is to hash and compare Block 4 of SWIFT messages (the most substantive of the five blocks of information). The text of Block 4 will typically be identical in duplicate SWIFT messages and will yield the same hash values. When matching hash values are detected, you can omit the duplicate messages from further analysis.

No. 7: Approach message linking with care

Sometimes banks can send more than one SWIFT message to accomplish a single transaction, as Crédit Agricole did trying to bypass U.S. economic sanctions. But linking messages is challenging. There’s no right or simple way to accomplish it.

To start, you can conduct a basic distribution analysis of SWIFT messages by message type. You might find that most messages are represented by a few different message types, or that some message types appear to be more significant. Then, based on the most prevalent or significant types, you can review the SWIFT manuals to determine which message types should be accounted for in a linking procedure. You can also ask the bank’s professionals how they actually use SWIFT messages to conduct transactions. There might be idiosyncratic protocols covering message combinations.

Once you’ve identified which message types to link, you can develop specific plans for each message-type combination. The order of the linking procedure matters. For example, when attempting to link an MT103 (credit transfer) with another MT103, you must decide in advance whether to target only unlinked messages, or messages already linked in earlier steps. Then design the sequence accordingly.

Be mindful of false positives and false negatives when linking. Since the reference fields of a SWIFT message often contain unique transaction reference numbers, they can be the most useful fields to use for linking. Unfortunately, there isn’t a technical requirement that these reference numbers be unique; banks often populate these fields with generic content such as “NOREF” or “00000,” which leads to false positives.

Exclusion lists can be extremely useful in preventing false-positive links. An exploratory analysis of the data set prior to linking can uncover references that should be excluded. Take an iterative approach to linking, checking accuracy at each step and looking for unusual or unexpected results.

Be prepared

You’ll be able to more easily achieve your investigative objectives if you invest time and effort into addressing the nuances and complexities of SWIFT message data extraction, storage and processing. Create an effective and efficient SWIFT message data framework — and follow these seven best practices — to decrease the time and money spent dealing with errors and exceptions in the early, preparatory stages of your investigations.

Jim Bracken, CFE, is a managing director in the Global Risk & Investigations practice at FTI Consulting and a contributor to the FTI Journal. He can be reached at: james.bracken@fticonsulting.com.