Millions of financial transactions are executed daily using the global messaging system known as SWIFT. These messages pose unique challenges for investigators. Here are seven steps to tackle them.
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 does not actually 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 would send a different kind of SWIFT message – without an identity – to the U.S. branch to convert the payment into U.S. dollars. In this way, the bank could access the U.S. financial system on behalf of its sanctioned clients without raising any red flags.
In fact, SWIFT messages – averaging almost 27 million sent per day in January 2017 across over 200 countries – 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. But while SWIFT messages are standardized, they are not very user-friendly, and there are a number of potential issues investigators encounter when extracting, processing, storing and analyzing 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 may encounter when preparing for a SWIFT message investigation.
As a result, SWIFT message investigations require significant planning and preparation. But there are seven best practices investigators can follow to increase the efficiency and effectiveness of their inquiries.
Step #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 may have regional data storage hubs; others may store SWIFT data locally at small branches or back offices. Given all the possibilities, it may make sense for investigators to ask a bank’s IT professionals to extract and transmit the data for investigation. However, if a high level of independence is required, investigators may have to deploy their own data extraction teams to the various storage locations.
Many financial institutions rely on third-party data storage providers with whom investigators must coordinate to extract data. These vendors may be less than enthusiastic about giving an outside team access to their facilities, so investigators should handle their communications with third parties with care.
The banking industry is also active on the merger and acquisitions front. So, investigators must consider what portions of SWIFT message data that a bank currently holds are relevant for a specific investigation and whether an acquiring bank may need to be contacted for information.
Step #2 – Assess Data Formats
Investigators should ask the banks involved in what format they store data to best prepare for accessibility issues.
Some IT departments back up their data onto tape cartridges that are stored offsite, incurring a significant time lag to either retrieve or restore them via the appropriate system.
Many SWIFT messages are archived using formats typical of text-based data; others are saved in a format specific to SWIFT, like MEAR files, in which other files types containing the SWIFT messages are embedded. In order to access that message data, investigators must restore the MEAR file to the SWIFT platform using SWIFT Alliance Access or compatible software. If these are not available, the data from the MEAR file must be accessed through its component files, which will require 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, investigators must decide whether it’s best to extract the enriched records, the original un-enriched SWIFT messages or both.
Step #3 – Determine Appropriate and Secure Extraction Techniques
When extracting SWIFT message data and transporting it to another location for analysis, investigators must adhere to best practices regarding chain of custody and data security.
In many cases, it may not be feasible to transfer data electronically from a bank’s network to the investigator’s site. The data sets may be too large or the connections too slow to use Secure FTP (SFTP), for example. Similarly, emailing large volumes of data may not be technically feasible or, just as importantly, could pose security and data integrity risks. Therefore, one option to consider is transferring the data to an encrypted hard drive and sending the 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.
Investigators should make sure that chain of custody documentation includes: 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 by the investigator match the originals held by the institution. Several free and easy-to-use hashing tools are available online.
Step #4 – Plan for Onsite Quality Control
It’s best to tackle issues with data quality onsite, so investigators should ensure they have the tools required to deal with predictable challenges.
The most crucial quality control procedure is searching for data gaps. Expected but missing SWIFT messages are red flags. Investigators can check for such 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, for example, the investigator can then consult with the bank’s IT and operations professionals to determine why. There could have been a system outage, a bank holiday, an emergency closure, a data backup error or perhaps simply an unusually slow business day.
It’s not unusual for institutions to archive incoming and outgoing SWIFT messages in separate directories. Investigators should 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.
Another data quality issue is the truncation of SWIFT messages caused by character limits imposed during archiving or even a system bug. Investigators should bring along a utility that can count the number of characters for each SWIFT message and review them for patterns, like repeated or round-number character counts.
It’s also a good idea to interview bank employees about data storage policies, archiving schedules and SWIFT administration so that investigators can be alerted to other data quality issues.
Step #5 – Understand Data Filtering Issues
Investigators must 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 may be at issue. Or the inquiry may be limited to a specific time period. The investigator must devise a plan for isolating in-scope from out-of-scope messages.
If the scope is limited to certain jurisdictions, investigators can begin by filtering the 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 United States. However, BICs can also be included in other SWIFT message fields, and although these other fields commonly contain BICs, many of them also allow the SWIFT user the option of entering the name and address of the bank rather than the BIC. Therefore, a keyword search for U.S. terms, including cities and states, may also be needed to arrive at a more complete data set. The investigator also should 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, filtering for the fifth and sixth characters should be augmented by a keyword search for countries, cities or states.
Filtering SWIFT messages by investigative scope can be tricky. Some SWIFT messages may show transactions in more than one currency, such as a foreign exchange transaction. Some messages may be related to letters of credit spanning time periods that only partially overlap a targeted date range. Investigators should consider the impact of such complications on the investigation.
Step #6 – Address the Mirror Message Issue
One of the biggest problems investigators encounter when processing SWIFT message data for analysis is the presence of duplicate messages. 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 has created two copies of the same message – one stored in Frankfurt and one in New York.
An investigator conducting data extractions at both locations would end up with duplicates in his or her data set. These “mirror messages” are compounded when dealing with large, global financial institutions with dozens of locations, creating a potential time-and-resource sink for investigators who must weed out extraneous messages that could distort their understanding of 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 text of Block 4 will typically be identical in duplicate SWIFT messages and, thus, yield the same hash values. When matching hash values are detected, the investigator can then feel comfortable omitting the duplicate messages from further analysis.
Step #7 – Approach Message Linking with Care
Banks can sometimes 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 is no right or simple way to accomplish it.
To start, though, investigators can conduct a basic distribution analysis of SWIFT messages by message type. They may 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, they can review the SWIFT manuals to determine which other message types should be accounted for in a linking procedure. Investigators can also ask the bank’s professionals how they actually use SWIFT messages to conduct transactions. There may be idiosyncratic protocols covering message combinations.
Once investigators have identified which message types to link, they can develop specific plans for each message-type combination. The order of the linking procedure matters. For example, when attempting to link an MT103 with another MT103, an investigator must decide in advance whether he or she is targeting only unlinked messages, or messages already linked in earlier steps, and design the sequence accordingly.
It’s important to 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 is no technical requirement that these reference numbers be unique; banks often populate these fields with generic content such as “NOREF” or “00000,” leading 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. Small changes in dates or values also can impact linking results. A gap in the time between when messages are sent or processed and the transaction date encoded in the message can cause a false-negative link, as can a small processing fee deducted from the intended payment.
It’s best to take an iterative approach to linking, checking accuracy at each step and looking for unusual or unexpected results.
Addressing the nuances and complexities of SWIFT message data extraction, storage and processing is just the beginning of an investigator’s work. But investing the time and effort into planning for the issues likely to arise is important to achieving an investigation’s objective. Creating an effective and efficient SWIFT message data framework – and following these seven best practices – can decrease the time and money spent dealing with errors and exceptions in the early, preparatory stage of an investigation, making it possible to allocate greater resources to the later, more critical stages.
A version of this story originally appeared on Fraud-Magazine.com