The Regulatory landscape and SWIFT messages
Cross-border payments have been a central theme in recent regulatory actions where regulators levied record breaking fines against financial institutions that failed to comply with Bank Secrecy Act / anti-money laundering (BSA / AML) regulations. The Society for Worldwide Interbank Financial Telecommunications (SWIFT) is, in some sense, at the heart of these violations because it is one of the major facilitators of global money transfers which have come under increased scrutiny.
The enforcement actions came about for a range of reasons, but a general assertion made by regulators in many of the major violations was that banks had inadequate Bank Secrecy Act / anti-money laundering (BSA / AML) programs. A press release issued by the Department of Justice (DOJ) illustrates how regulators perceive failures of anti-money laundering (AML) programs to be a major infraction by financial institutions.
“A four-count felony criminal information was filed today in the District of Columbia charging Commerzbank with knowingly and willfully conspiring to commit violations of IEEPA and Commerz New York with three violations of the BSA for willfully failing to have an effective anti-money laundering (AML) program, willfully failing to conduct due diligence on its foreign correspondent accounts, and willfully failing to file suspicious activity reports. Assuming the bank’s continued compliance with the deferred prosecution agreement, the government has agreed to defer prosecution for a period of three years, after which time, the government would seek to dismiss the charges.”
What does an effective anti-money laundering (AML) program mean?
Effective anti-money laundering programs involve a wide variety of activities, resources, leadership and technology, but for the purpose of this article, the focus will be to discuss what improvements can be made when mapping SWIFT messages to transaction monitoring systems (TMS) and the common pitfalls and data quality issues which arise from this endeavor.
Transaction monitoring systems (TMS) are software applications which have been specifically designed to assist financial institutions to satisfy their BSA / AML requirements by leveraging pattern recognition algorithms that detect activity abnormalities and other money laundering typologies. Financial institutions involved in cross-border payments may be members of SWIFT, and consequently some of the institution’s SWIFT traffic may be subject to BSA / AML monitoring requirements based on their local jurisdiction's rules and regulations.
Mapping SWIFT messages to transaction monitoring systems (TMS)
Data mapping can be a difficult task in itself based on the wide variety of source system applications and middleware a financial institution can be supporting, but some transactional activity is more complex than others to map based on its structure and the number of data elements involved. This is particularly evident when a financial institution maps SWIFT messages to its transaction monitoring system (TMS). Some of the challenges stem from, but are not limited to the following:
- Number of entities involved in the message
- Financial institutions, large corporations, businesses and individuals
- Different SWIFT message types and formats to facilitate various banking functions such as trade finance, foreign exchange, securities settlements, cross border payments, etc.
- Periodic updates and changes to SWIFT message formats and validations
- Free text format of certain fields
- Options to represent the same data differently in the same field
- Large reference data sets required to extract the necessary data for Compliance
- Development of in-house message parsing tools subject to limitations and inaccuracies
- Inflexible vendor solutions that can parse messages, but not to the extent needed for transaction monitoring systems (TMS)
- Knowledge gap between personnel in payment operations and the individuals implementing the transaction monitoring systems (TMS)
Levels of complexity
Financial institutions can vary quite significantly in terms of how sophisticated their monitoring of SWIFT messages is, but all are subject to a certain level of inaccuracy. The table below illustrates three levels of complexity for the mapping of SWIFT messages to a transaction monitoring system (TMS).
Correspondent banks and other financial institutions
Financial institutions which support correspondent banking will be inclined to implement the intermediate and advanced levels of SWIFT message mapping, especially in the more developed countries, because of the amount of scrutiny placed on banks from regulators for engaging in this business. Correspondent banking is considered very risky because the correspondent bank providing clearing services to their respondent banks are predominantly relying on their respondents to have an adequate BSA / AML program. However, respondent banks generally will abide by the rules and regulations of their host country which could differ from the correspondent’s and the perception and risk appetite of each institution can also vary widely.
Financial institutions which do not provide correspondent banking services can still benefit significantly from implementing the intermediate and advanced level of SWIFT data mapping because of the increased detection capabilities the data offers.
If a SWIFT message is not parsed correctly it could misrepresent which role each financial institution played in the message such as the originating bank, sending correspondent, receiving correspondent, beneficiary bank or other type of intermediary.
1. Bank roles and countries in the message flipped
The diagram below represents a MT103 SWIFT message where there are four banks and two customers involved in the message. However, the originating and sending correspondent bank roles have been flipped and the actual sending correspondent bank is represented as the originating bank, and the originating bank appears as the correspondent.
2. Wrong bank and country represented in the message
In the second example in the diagram below, the financial institutions are not flipped, but the originating bank is actually represented incorrectly. The originating bank appears to be located in Mexico, but the bank is actually located in France.
3. Key risk attributes missed in basic mapping model
Another more insidious example that represents the limitations and lack of transparency of mapping SWIFT messages according to the basic level of complexity is shown in the diagram below. First, the originating bank and its country code is unable to be identified because the basic parsing model expects a SWIFT (BIC) to be supplied, but the originating bank’s name and address was populated instead. Second, the basic parsing model is not sophisticated enough to extract the country codes from the originating and beneficiary customer address fields and consequently this key information is blank.
If the mapping model was able to extract the country code from the originating and beneficiary customer address fields, then the Compliance department would have the opportunity to create a new detection scenario such as the customer banking outside of their jurisdiction. While there are instances where an entity can have a legitimate reason to bank outside of its jurisdiction it is an important risk indicator that can be leveraged and help the institution fine tune its system by implementing a more targeted and risk based approach.
Why does accuracy matter?
While on an individual transaction level the inaccuracies described above may appear to be trivial, on a macro scale it could severely undermine a financial institution’s ability to monitor abnormal deviations in its SWIFT message traffic per country, financial institution and customer. Also, inaccurate SWIFT message parsing can have a detrimental effect on a correspondent bank’s ability to detect its respondent banks deviating from their anticipated activity profile which is usually captured when a new bank is on boarded by the correspondent. Deviations in historical activity at the SWIFT (BIC) level could also be an indication that a respondent bank “may” have been de-risked by another correspondent bank and consequently SWIFT traffic needs to be rerouted accordingly.
Another use case for deviations in historical activity is at the country level which could serve as an indication of geopolitical risks. For example, the diagram below represents the aggregation of Mongolian banks SWIFT message traffic over a 17 month period with a significant spike in activity when compared to its historical profile. From January 2013 through April 2014 the average value and volume for Mongolian banks has been $5.6M and 378. However, during the month of May 2015, the value and volume activity totaled $31M and 2,400 respectively. This deviation from the historical profile amounted to a percent change of 472% and 535% as shown in the table below. The spike in activity originating from the Mongolian banks coincided with new sanctions being imposed on Russia by the United States - and Mongolia happens to be in proximity to Russia.
While the above observation doesn’t imply causation, it does provide an interesting statistic for the financial institution’s compliance department to consider investigating. What is driving the sudden increase in SWIFT message traffic from the Mongolian banks and does it pose additional risks which can be mitigated? Conversely, if the spike in activity is innocuous because the financial institution recently expanded its footprint in the region then this explanation can be recorded and documented by the Compliance department to ensure senior management can explain this scenario to internal auditors and possibly regulators which alleviates the risk of the event being construed in a deleterious context.
Mongolian banks value and volume percent change from historical profile
Average last 16 months
Mongolian banks: SWIFT value & volume historical profile (17 months)
Transparency is the goal
The target state of any financial institution initiating or receiving SWIFT messages should be to have the greatest amount of transparency of their SWIFT traffic based on their risk appetite. Ideally, mapping SWIFT data to a transaction monitoring system (TMS) will allow the financial institution to accurately monitor deviations from historical profiles per country, SWIFT (BIC) and customer. Additionally, extracting country codes from the originating and beneficiary customer's address fields will allow for unique opportunities for custom data analytics and detection models such as customers banking outside of their jurisdiction.
These are some small improvements with low implementation costs which could make a big difference to how risky transactions and correspondent banks can be identified and managed. The question is, why aren't banks already making better use of the SWIFT data they have at their fingertips?
Keith Furst, Founder of Data Derivatives discusses how banks may be exposing themselves to unneccessary risk of compliance violations and fraudulent transactions by failing to extract important information from their SWIFT message traffic. In this guest post, he explores how banks can better map and analyse their SWIFT message data to identify and mitigate risk.