Financial institutions must comply numerous regulations, and keep a close eye on all transactions to spot suspicious events and assist crime prevention. This means analyzing copious amount of data daily, which is never an easy task. Fortunately, software solutions can help to ease the burdens that come with regulatory compliance. Nonetheless, these solutions sometimes need a bit of refinement to fit to the actual operation of the bank.
Our customer already had a program to filter any transactions that involved restricted parties. A proprietary batch script was used to extract party information from SWIFT messages and compare them against a Sanctioned Parties List (SPL). The system worked well as long as there was no Chinese bank involved in the transaction. However, if the originating or the intermediary bank was based in China, the SWIFT message contained information in Chinese Telegraphic Code (CTC), which couldn’t be decoded by the batch script. This prevented the batch script to run the SPL-check on the party information. Needless to say, CTC based transaction messages provided a huge risk in OFAC compliance.
We aimed to resolve this practical problem by adding to the existing solution instead of creating a new software for the entire process from scratch. Our objective was to help our customer to make the best use of the otherwise well-operating software investment. During design and development, we also needed to consider several compatibility issues and pay a close attention to the ecosystem. Our software was required to integrate well with IBM MQ, Oracle BAM, and Windows File System based queues. We also had to make sure that there would be no interference with the core-banking operations. The solution had to be compatible with both SWIFT and Fedwire message formats.
To address and resolve the CTC-anomaly, we started with creating a custom database containing the Pin Yin reading of the 9000+ CTC codes. Then we added a software service to scan each SWIFT name field to identify any CTC. If the message included any CTC, the program assembled a string of Chinese characters for the given string of codes. The assembled characters were transliterated to English by a translating integration using Google, Bing, or Babylon API; and the resulting name was forwarded to the existing batch program of the bank for SPL-check. An exciting challenge we faced and solved during development was how to secure on-demand interaction with Google or Bing translation service.
To make transliteration more efficient and precise, we also included a user interface. This allowed the users to view and correct the translations. The correction could also be saved for future use. The program was also able to memorize patterns avoiding any re-translations. Thus, the process became more efficient.
At the end of the day, our software integrated efficiently to the existing SPL-checking program. It also runs smoothly without influencing the operation of the core-banking system or any other part of the ecosystem. It also successfully fulfilled its main objective: mitigating the risk of non-compliance with OFAC regulations when the party information was received in CTC.
If you are interested in a similar solution, visit our services page or contact us.
- mitigating OFAC compliance risks in case of CTC transaction messages
- software integrating into the existing SPL-checking batch script
- integration with IBM MQ, Oracle BAM, and Windows File System based queues
- non-interference with Core-Banking operations
- message formats: SWIFT and Fedwire
- custom CTC to PinYin transcription database
- software identifying CTC and paring them with Chinese characters
- integration Chinese to English translation
- forwarding English translation to SPL check
- user interface for revising and correcting translations
- process optimization with pattern learning