niceideas.ch

Artificial Intelligence and fraud prevention with Netguardians' CTO, Jérôme Kehrli

2022-01-18T06:11:45-05:00

I spoke to to Rudolf Falat, founder of the Voice of FinTech podcast about leveraging AI in anti-fraud prevention and cybersecurity.

The Podcast is available here and can be listened to directly from hereunder:

Happy listening !

The full transcript is available hereunder

Jerome, can you introduce yourself? How did you get to do what you do today?

I'm swiss, 43 years old and a proud father of 3 boys.
I guess I'm first and foremost a passionate software engineer and computer scientist. I remember putting my hands on my first computer - a commodore 128 - when I was 12 years old and knowing very well at that very moment that that would be my carrier.
I'm passionate by technology, artificial intelligence, programming, etc. for nearly 30 years now. I made all my career in financial institutions and fintechs and I wouldn't see myself working in another business nowadays. Financial institutions and financial markets form a very interesting domain of application in computer science due to the complexity of these systems and the wide range of concerns to be addressed, from real-time computing to highly mathematical applications.
I guess that my role today as CTO of NetGuardians is kind of a natural evolution in my career.

NetGuardians is a Swiss based software editor developing a Big Data Analytics platform that we package and deploy in financial institution mostly today to detect fraudulent activities and prevent fraudulent transactions.

Why have you decided to join a start-up (or a scale-up) like NetGuardians?

Before the NetGuardians co-founders reached out to me I was a consultant for a few years, working mostly for the major european banking institutions.
I really liked the job at the time, mostly the possibility to jump quickly from one topic to another, one customer to another.

But I did miss the product culture very much. As a consultant I was guiding other teams or leaders in adopting technologies, designing information systems, driving innovation projects, etc. But I was missing the deep implication and engagement that you get when you create a product from A to Z and sell it. Developing a software is the closest you can get in day job to having an actual child ;-)

So when NetGuardians pivoted to banking fraud fighting 7 years ago, the co-founders were looking for someone to lead the product research and development department, someone with a strong technical background and an extensive experience in finance.
Switzerland is a small country so they have been directed by some common relationship we had in their advisory board to my profile. So we met and they told me their story and shared their vision with me and I decided that I wanted to be part of it.
And today, 7 years after this first encounter I guess this company and this product are just as much my children as they're theirs.

When will we finally have truly intelligent AI working on fraud prevention in banking ?

Now that's a good question.
It's hard to answer since intelligent AI would need to be defined or precised. So first I would want to distinguish strong AI vs. weak AI and then share my perspective on what would be a truly intelligent AI.

If we qualify as a strong artificial intelligence, a software program able to contextualize, to show sensitivity, to show creativity or to exceed it's programming scope, then we don't have today the slightest trail of a proof that we'd be able one day to create such an program. This is downright science fiction. There is nothing in the real world anywhere close to the beginning of it.
The thing is that Artificial Intelligence is generating a lot of fantasy in the public's mind and I guess that the fact that we have given some of these algorithms names such as neural network is not helping in this regards. If we had given to neural networks the technical names they should have, such as largely convoluted and iterative statistical matrix model, I'm sure they wouldn't generate the same level of fantasy in people's minds.
Anyways.

Then if we qualify as a weak AI a software program able to optimize a mathematical function, solve a classification problem, or take a decision based on input data, then the progresses today are tremendous and new applications and solutions pop up nearly every week.
This technology evolves at a very fast pace and today's AI programs are a collection of sometimes hundreds of different algorithms working together to solve an analytical problem, such as driving a car autonomously for instance which is amazing.

Now when it comes to true intelligence, I strongly believe that the only true, actual intelligence is in the mind of the people developing these systems, not the machine, never the machine.
And then again, the progresses today are tremendous and essentially around 2 dimensions: the complexity of the individual Machine Learning algorithms and the number of these algorithms deployed together and working in conjunction in Artificial Intelligence Systems

And what we do at NetGuardians is a good illustration of all this evolution.
When we started in 2016, we were using one or two different methods to infer good features on events we were monitoring, mostly EBanking activities and financial transactions, as well as a single Supervised learning algorithm. Today we use a combination of multiple dozens of different unsupervised and supervised techniques all working together and each one of them focusing on a specific perspective, such as the timing of events, their frequency, their location, the destination of the funds, etc. or a specific step in the risk scoring process.

So yeah, again the true intelligence is in the mind of the guys developing these systems, not in the software.

How good is anti-fraud AI today? What kind of AI are we talking about?

Anti-fraud systems today form a very peculiar and passionate domain of application for artificial Intelligence. The nature of the problem to be solved makes it very specific.
Think of it, while some payments channel such as credit cards for instance experience a plethora of frauds, some other channels such as digital banking payments have typically only a few frauds for a million transactions a day.

Most sophisticated classification machine learning algorithms we have today perform very poorly on such datasets. They work well when the data is very much balanced between the positive and other populations.
As an example, every engineer knows today how to train a neural network to recognize pictures of cats, for instance, by feeding it with thousands of pictures of cats and thousands of pictures of other animals and other objects. Now if you try to train a neural network to recognize cats with only 6 pictures of cats and millions of random pictures of other animals and objects, the next picture of a cat you will present to the neural network will be classified as anything, such an elephant, right ? But there's no way an algorithm trained this way understands how to recognize cats.

And we're in the same situation. The very unbalanced nature of the data we're playing with makes all simple approaches simply irrelevant. So we have to do fairly complex stuff.

Our state of the art approach today at NetGuardians is a combination of multiple fairly evolved techniques and approaches working together.
I don't want to go to much into technical details but I would mention three categories of techniques we're using.

First, unsupervised learning techniques for anomaly detection ... with a wide range of different algorithms, from simple statistical or Poisson scoring down to clustering and peer group analysis. At the end of the day, fraudulent activities and transactions are always part of the set of anomalies.
Then, supervised learning techniques ... with a lot of different models being required from classification algorithms to risk scoring techniques, to distinguish between legitimate anomalies and highly potentially fraudulent transactions.
Last but not least, active learning and other supervision techniques to monitor the feedback we get from banking business users reviewing the hits, the activities or transactions being blocked in real-time by the system, etc.
And that is absolutely key because at the end of the day, our algorithms learn a lot from the feedback of these business people and they can only be as good as this feedback is. So supervising this quality is an essential concern.

So yeah, again, our approach at NetGuardians today is a combination of dozens of such techniques and algorithms deployed together to detect and block suspicious activities and transactions in real-time. And It works pretty good !

Another thing to consider: every transaction we block is investigated by a business expert within the bank who takes the eventual decision.
In a sense, we're not replacing the human decision process, but we're enhancing it. We give bankers a chance to review potentially or likely fraudulent activities before the funds leave the bank. And this is called Augmented Intelligence.

Who are your target customers?

At NetGuardians, we're working only for financial institutions. Our typical customers are Tier 1 and Tier 2 banks - big banks to medium size banks - where we detect fraudulent activities in a holistic fashion, fraudulent transactions and activities on digital channels just as much as internal fraud or scams.
In terms of types of financial institutions, we work just as much with massive retail banking institutions in Asia than private banking institutions in Switzerland.
Our key markets are Europe, our home market, Africa and Asia Pacific.
We support on premise deployment for Tier 1 banks who have a strong will to keep everything in house and onboard smaller institutions on one of our SaaS - Software as a Service - platforms on the cloud.

How do you make money?

Our customers pay an annual recurring licensing fee calculated from two metrics, their Asset under Management and their volume of financial transactions.
We bill delivery and integration costs when we integrate the solution ourselves but we intend to get away from this activity as much as possible and rely increasingly on local partners for integration.
We are not very much interested to sell services and would want to focus in the future on selling licenses only but that would require us to reach a critical mass and we're not there yet.But it's an ultimate objective for us, moving a way from a being both a product and service company today and turning to an only product company.

Where are you based?

We're a company founded in Switzerland and we are still today headquartered in Yverdon-les-bains, a small town north to Lausanne. We have offices in Nairobi where we manage our operations in Africa and in Singapore where we handle our Asian activities. We also have a commercial office in London and a near-shore development center in Warsaw .

Where are you on your journey in terms of product development, geographic reach, funding, hiring? Any numbers you can share?

We have today a very solid technology and product for the banking fraud detection and prevention problem. And in the short term we intend to leverage on our technology to extend our product to other financial crime use cases.

There are many different concerns in Financial crime fighting in banking institutions, Fraud detection is an essential one of them of course but then there's also AML - Anti Money Laundering - Transaction Monitoring, KYC - Know your customer and of course customer and transaction screening.
KYC and screening require very different technologies than the ones we've built so they're not in our short term focus. But AML Transaction Monitoring is very close from what we do on Fraud, just the perspective of the analytics is somewhat different.
Finding fraud is a lot about understanding where the money goes while AML is a lot about understanding where the money comes from, but from a technical standpoint it's really similar.

So long story short, we intend by the end of next year to extend our solution to state of the art AML transaction Monitoring leveraging on our technology. Eventually, over the next years, we intend to build a complete financial crime package by integrating third party solutions for KYC and screening.

In terms of geographic reach, we are today strong in Europe - our local market - and Africa. But we're really only building Asia. This is where we are investing our effort today and in the coming year to build a strong sales team, identifying and leveraging on the right partners, scaling the delivery team and eventually, hopefully, become a major player in Asia as well.
Interestingly, we have no intent to actively address the US market today aside of a few opportunistic leads through some of our partners.

To give you a few figures, we're today a 100 FTEs company and we have a little less than 80 financial institutions as customers.

Now regarding funding, I can't tell you much actually. We have raised roughly 30 million USD so far and we are in the process of challenging and building the next investment round. Building the proper structure in APAC to emerge as a major player here is not something on our reach today. We need support from investors to build this and we're working on that today.

What are the next steps for you next year and beyond? Customers, incumbents as partners, investors?

We intend to develop significantly in our three key markets, Europe, Africa and Asia. We are in the process of finalizing recruitment of the key people - such as regional sales director, etc. - who will be instrumental in driving our growth in these regions.
And as I said before, we need support from investors to build the proper structure in APAC, based in Singapore.

In terms of partnership, we have today very good partners in the core banking systems and banking package providers field where our strategy is to bundle our fraud detection engine with their Core Banking Package offering.
We are now in the process of looking for integration partners in the different regions to support our scaling and incrementally disengage our own people from delivery.

In terms of investment, we would also expect the next round to support our extension to completeness of offering in AML and more generally financial crime fighting as well as complete our transition to the cloud as lead deployment channel. We have still quite a path ahead of us to provider tier 1 banking institutions with a state of the art hybrid cloud approach.
A lot of tier 1 banking institution would sign up for a cloud deployment of NetGuardians if and only if we can provide them with means to guarantee that the confidential data remains within the bank information system boundaries. And the technology for that is called hybrid cloud which would be quite an evolution from what we do today.

Where can interested parties reach you?

Well, I guess the best way to get in touch with us is through our web site, www.netguardians.ch.
And the best way to contact me would be on linkedin I guess jerome KEHRLI.

NetGuardians' 3D AI Technology

2021-06-08T03:18:54-04:00

(Article initially published on NetGuardians' blog)

Whenever our software is run head-to-head in a pitch situation against that of our rivals, we always come out top. We always find more fraud with a lower number of alerts. For some, this is a surprise – after all, we are one of the youngest companies in our field and one of the smallest. To us, it is no surprise. It is testament to our superior analytics.

A focus on customer behavior

We began working in fraud prevention in 2013 and quickly realized the futility of rules engines in this endless game of cat-and-mouse with the fraudsters. The criminals will always tweak and reinvent their scams; those trying to stop the fraud with rules engines will always be left desperately working as fast as possible to identify and incorporate the latest scams into their surveillance. Far better to focus on what we know changes very little – customer behavior.

If a bank knows how a customer spends money, it can spot when something is awry by looking for anomalies in transaction data. However meticulous the fraudster is at trying to hide, every fraudulent transaction will have anomalous characteristics. People’s lives are constantly changing – they buy from new suppliers, they move house, go on holiday and their children grow up – all of which will affect their spending and transaction data. Every change will throw up false alerts that will undermine the customer experience unless you train your models correctly.

The three pillars of 3D AI

We train our models using what we call our 3D AI approach. This enables them to assess the risk associated with any transaction with extraordinary accuracy, even if it involves new behavior by the customer. This also keeps false alerts to the minimum.

Developed by us at NetGuardians, this approach has three pillars, each of which uses artificial intelligence (AI) to constantly update and hone the models.

The pillars are: anomaly detection, fraud-recognition training analytics and adaptive feedback. Together, they give our software a very real advantage by not only spotting fraud and helping banks stop fraudulent payments before any money has left the account, but also by minimizing friction and giving the best possible customer experience. This is what differentiates our software in head-to-head pitches.

The first pillar is anomaly detection, which is mostly unsupervised learning. At this stage, we are looking for anomalies and working out the level of risk associated with them. This involves examining a set of parameters such as time of transaction, counterparty, location, amount and currency. As seen above, on their own, these parameters aren’t enough to prevent an unacceptable level of false alerts. By including peer-group behavior, we begin to reduce the number of false alerts. For example, people don’t buy a car often and when they do, they don’t want their bank to block and query the transaction because of its rarity. But if you place the customer among peers, the size of the transaction can trigger associations that bring its risk level down. This, along with other techniques including Poisson Law help us understand the timing and regularity of the transaction, resulting in a highly nuanced picture of risk.

The second pillar is fraud-recognition training analytics, mostly relying on supervised learning techniques. Typically, a T2 or T3 bank might see 10 frauds a year out of 100 million transactions. This level of fraud is insufficiently high to train a complex algorithm. So we have developed models using anonymized bank data that can be overlaid on a bank’s own data. The models cover different situations, regions, size of bank and type of customer, which allow us to create analytics that look at the context of the data. Our software is even capable of deciding which model is best for the analysis.

For a T1 bank, it takes just a few hours to train the algorithms, with perhaps some manual intervention to confirm the final choice of models. Smaller banks take one to two hours and the process is fully automated.

The final element is adaptive feedback using active learning. This is absolutely crucial to reduce false alerts to the lowest possible level while minimizing the risk of missing a fraud. Our adaptive feedback technology monitors, controls, challenges and supervises feedback from the alert investigators – the bank’s back- and middle-office employees who review alerts and decide when to call the customer – to ensure that it is of sufficient quality before re-injecting it into the machine learning models. As this is unique to the NetGuardians approach, it’s worth going into a little more detail.

Fine-tuning and machine learning

All alerts raised by the NetGuardians software come up on a dashboard and have to be reviewed manually. If the alert turns out not to be a fraud, we ask the bank to classify the risk of transaction.

High = not a fraud but confirmed as high-risk, so continue to block similar transactions
Medium = not a fraud but can see why NetGuardians software thought it would be. Proceed with care
Low = not a fraud and unclear why the software thought it was. Never block similar again

This feedback retrains unsupervised and supervised learning and is key to the precision of our solution. Further tuning comes from the ability of our software to query feedback to ensure it is high quality.

For example, someone has been working in fraud investigation for many years. They have “learnt” that usually just two parameters reveal suspicious behavior – let’s say the amount and the beneficiary – and use only those two to decide the level of risk. When applied over and over again, a model would learn to look at just those two features, undermining its ability to see and learn from the whole picture – a form of “overfitting”. This reduces its accuracy. But our software does something very clever. If it believes something is anomalous, it will ask the investigator a direct question about another parameter, forcing them to re-examine the transaction. It then uses this additional feedback to learn more about the customer, the bank and the transactions.

Taken together, these three pillars of AI are responsible for our market-beating performance. Only NetGuardians uses these three together. And only NetGuardians is able to find all the fraud a bank knows about in historic data as well as up to nearly one-fifth more. Our software doesn’t need to be taught new fraud types because it isn’t looking for them. And it doesn’t add customer friction – in fact it reduces false alerts by as much as 83 percent. This is because it is always learning and refining its models across the broadest possible perspective, resulting in our analytics supremacy.

(Article initially published on NetGuardians' blog)

AI - opportunities and challenges for Swiss banks

2019-12-06T11:00:58-05:00

Yesterday we were amazed by the first smartphones. Today they have almost become an extension of ourselves.
People are now used to be connected all the time, with highly efficient devices on highly responsive services, everywhere and for every possible need.

This is a new industrial revolution - the digitization . and it forces corporations to transform their business models to meet customers on these new channels.

Banks worldwide are on the first line in this regards and for many years now they have well understood the urgency in proclaiming digitization as a key objective.
From a user perspective, the digitization confers enormous benefits in the form of ease, speed and multiple means of access and a paradigm shift in engagement. Since banking as a whole benefits from going digital, it is only a matter of time before operations turn completely digital.

The journey to digital transformation requires both strategy investments as well as tactical adjustments in orienting operations for the digital road ahead.
Fortunately, if technology can be perceived as a challenge, it is also a formidable opportunity.
And in this regards, Artificial Intelligence is a category on its own.

Artificial Intelligence and it's potential in the banking business.

AI provides a unprecedented opportunity to make banks smarter. Deploying AI solutions in banking leads to better customer intelligence and better customer experience.
Both are key to increase benefits and reduce operational costs.

There are multiple applications for AI solutions in the banking business around three major axis:

Customer Experience revolution when putting technology in direct contact with the customer
AI analytics improving operational efficiency in various domains (e.g. investment research, credit scoring, etc.) or providing personalized advisory to customers
Risk mitigation with better fraud detection, more efficient AML, more efficient compliance controls, etc.

One of the most impressive opportunity on the customer experience revolution axis is formed by chat-bots and voice assisted banking. The need for physical presence is definitely fading and technology empowers customers to use banking services using voice commands and touch screens.

In regards to improving operational efficiency within the bank, the most promising evolution comes form the conjunction of Real-time Big Data processing with Machine Learning. The technology can provide personalized, value-added products to customers as it learns about spending habits or investment profiles, but it can also automate most analytics duties within the bank.
Data-driven AI applications are intended in the future to cover the whole range of financial decisions: advisory, calculations, scoring and forecasts, for the bank as well as for the customers. For instance if approving a commercial real estate loan was traditionally a several days process within a bank, using AI will reduce it to a few dozen of minutes.

Last but not least, embracing AI has been at the root of significant improvements in Fraud detection and AML. Companies like MasterCard and Visa have been using AI to detect fraudulent transaction patterns for several years now. At NetGuardians we deploy AI solutions for digital banking fraud prevention and internal fraud detection for several years as well.

AI solutions are key to react proactively and inform the customer before the funds leave the bank. AI enables to implement Transaction analytics but also behaviour analysis aimed at catching more complex fraud patterns.

What about Swiss banks ?

Interestingly, while most would describe Switzerland as less innovative than other countries such as UK for instance, especially in the retail banking space, the reality is a quite differentiated picture.

The digital solutions of the major Swiss banks are among the best in the world and Machine Learning algorithms are used down the line on the three axis described above. Due to their conservative nature, the major Swiss banks have a tendency to rather follow the market best practices and state of the art in terms of customer experience evolution but on the backend side - the technology running under the hood - they are rather very well in advance.

The situation of smaller Swiss retail banking institutions is somewhat similar. Their strong footprint in their regions, their attractive conditions as well as their good digital banking solutions in general relieves the pressure. The biggest difference with major banks is that smaller institutions don't necessarily have the ability to research AI or Machine Learning technology on their own so they rely on third party providers such as NetGuardians for fraud prevention or other fintechs for other use cases.
In this sense, keeping a close proximity with engineering schools and universities is a tremendous opportunity to stay on the top of the game and get in touch with the numerous fintechs flourishing in Switzerland. One could only advise them to be less timorous when it comes to supporting these startups since investing in them is eventually their only way to support the development of the technology that will be available to them in the future.

Private banking institutions on the other hand are more vulnerable today, at least for the smaller ones. Their margin is reducing and their wealth management business is increasingly cannibalized by other actors such as External Asset Managers, Fintechs or bigger institutions - even retail institutions where AI has been instrumental into making them reach a level of proximity in advisory that was so far the exclusive privilege of private banks.
Private banking institutions need to understand the urgency in revolutionizing the private banking customer experience and recover the lead in this regards from the other actors. Here as well the opportunities for Artificial Intelligence applications are striking: operational efficiency, advisory, etc.

Dissecting SWIFT Message Types involved in payments

2019-04-05T05:40:51-04:00

In my current company, we implement a state-of-the art banking Fraud Detection system using an Artificial Intelligence running on a Big Data Analytics platform. When working on preventing banking fraud, looking at SWIFT messages is extremely interesting. 98% of all cross-border (international) funds transfers are indeed transferred using the SWIFT Network.
The SWIFT network enables financial institutions worldwide to send and receive information about financial transactions in a secure, standardized and reliable environment. Many different kind of information can be transferred between banking institution using the SWIFT network.

In this article, I intend to dissect the key SWIFT Messages Types involved in funds transfers, present examples of such messages along with use cases and detail the most essential attributes of these payments.

These key messages are as follows:

MT 101 - Request for Transfer
MT 103 - Single Customer Credit Transfer
MT 202 - General Financial Institution Transfer
MT 202 COV - General Financial Institution Transfer for Cover payments

This article presents each and every of these messages, discuss their typical use cases and details key SWIFT fields involved.

Summary

1. Introduction to SWIFT
2. Dissecting key SWIFT Mesages involved in payments (Funds Transfers)
3. Conclusion

1. Introduction to SWIFT

SWIFT - Society for Worldwide Inter-bank Financial Telecommunication - is a Belgian company, located in Belgium, and is a trusted and closed network used for communication between banks around the world. It is overseen by a committee composed of the US Federal Reserve, the Bank of England, the European Central Bank, the Bank of Japan and other major banks.
SWIFT is used by around 11 thousands institutions in more than 200 countries and supports around 25 million communications a day, most of them being money transfer transactions, the rest are various other types of messages.

The majority of international inter-bank messages use the SWIFT network.
SWIFT does not facilitate funds transfer: rather, it sends payment orders, which must be settled by correspondent accounts that the institutions have with each other. For two financial institutions to exchange banking transactions, they must have a banking relationship beforehand.

1.1 Key SWIFT aspects

Internationally standardized messaging means that every transaction between every financial institution is recorded in exactly the same way, providing all the details in a clear and transparent manner.
Every financial institution has its own unique code that provides information on the name and location of the bank. Each transaction contains a unique reference number, bank operation code and details of charges incurred during the transaction.

Because SWIFT uses internationally standardized messages, it is a transparent way for institutions to communicate between each other and securely relay the details of any transaction. There are a number of known benefits to using SWIFT:

Transparency. SWIFT payments clearly detail the amounts involved in the transaction, the route it takes between banks, the details of all charges and the nature of the payment (along with many other details). This information allows all parties involved to track the transaction and to understand the costs and time period involved.
Traceability. Because SWIFT details the route of the transaction between banks and the amount of money involved, it provides clear and recognized proof of payment.
Consistency. Due to the consistency of how messages are structured, payment information is easy to decipher regardless of country or language barriers.

1.2 Correspondent banking

Correspondent banking is an important aspect of international banking and a key concept underneath the SWIFT network.

1.2.1 Correspondent Bank

A correspondent bank is a financial institution that provides services on behalf of another financial institution. It can facilitate wire transfers, conduct business transactions, accept deposits and gather documents on behalf of another financial institution. Correspondent banks are most likely to be used by domestic banks to service transactions that either originate or are completed in foreign countries, acting as a domestic bank's agent abroad.

Generally speaking, the reasons domestic banks employ correspondent banks include:

limited access to foreign financial markets and the inability to service client accounts without opening branches abroad,
act as intermediaries between banks in different countries or as an agent to process local transactions for customers abroad,
accept deposits, process documentation and serve as transfer agents for funds.

The ability to execute these services relieves domestic banks of the need to establish a physical presence in foreign countries.

1.2.2 Transferring Money Using a Correspondent Bank

International wire transfers often occur between banks that do not have an established financial relationship. When agreements are not in place between the bank sending a wire and the one receiving it, a correspondent bank must act as an intermediary. For example, a bank in Geneva that has received instructions to wire funds to a bank in Japan cannot wire funds directly without a working relationship with the receiving bank.
Most if not all international wire transfers are executed through SWIFT. Knowing there is not a working relationship with the destination bank, the originating bank can search the SWIFT network for a correspondent bank that has arrangements with both banks.

Interestingly, when a bank wants to send some funds to another bank on the other side of the world, it happens often that the sending bank has no banking relationships with any bank having itself a relationship with the target bank. In this case, the order needs to be transferred through several, sometimes many, distinct banking institutions through the SWIFT network.
These intermediate banks are called routing banks.

1.2.3 VOSTRO and NOSTRO accounts

General usage of NOSTRO/VOSTRO (they refer to the same account but different bank perspective):
A NOSTRO account is a reference used by Bank A to refer to "our" account held by Bank B. NOSTRO, is a shorthand way of talking about "our money that is on deposit at your bank."
VOSTRO is the term used by Bank B, where bank A's money is on deposit. VOSTRO is a reference to "yours" and refers to "your money that is on deposit at our bank."

1.3 Key SWIFT Message Types

When it comes to fund transfers, only a subset of the SWIFT messages are relevant:

Message Identification and Name	Space	Reference document
MT 101 Request for Transfer	Customer-to-Bank and Interbank	Standards MT November 2018
MT 103 Single Customer Credit Transfer	Interbank
MT 202 General Financial Institution Transfer	Interbank
MT 202 COV General Financial Institution Transfer	Interbank
MT 9XX - Confirmations and statements	Customer-to-Bank and Interbank

1.3.1 Detailed presentation of key SWIFT messages

These SWIFT messages are described as follows:

The SWIFT MT101 message is a request for transfer, enabling the electronic transfer of funds from one account to another. Funds are transferred from ordering customers account to a receiving financial institution or account servicing financial institution. For us right now, the important thing to note is that the message format that enables this transfer is the SWIFT MT101 format.
The MT103 is a SWIFT message format used for making payments. MT103 SWIFT payments are known as international wire transfers, telegraphic transfers, standard EU payments (SEPA payments), LVTS in Canada, etc.
Swift MT202 Requests the movement of funds between financial institutions, except if the transfer is related to an underlying customer credit transfer that was sent with the cover method, in which case the MT 202 COV must be used.
MT202 COV is a SWIFT message format for financial institution (FI) funds transfer between financial institutions. MT202's are used primarily for two purposes, bank-to-bank payments (i.e. interest payments and settlement of FX trades) and Cover Payments.
MT202 COV was implemented in 2009 to create traceability of the origination of funds (institution and account) through to the destination of funds (institution and account.) This was in response to anti-money laundering and associated banking requirements.
Prior to MT202 COV, The message format, MT202, did not include origination/destination financial institution information. Particularly for Cover Payments, where a combination of MT103 and MT202 are used to direct funds transfers to a beneficiary account, the intermediate banks in the MT202 had no ability to understand and perform risk analysis/AML/compliance checks on the funds transfer based on the original and destination of the funds. Thus, intermediate banks could be unwittingly involved in illegal transactions under new regulations.

1.3.2 Typical situation and use cases in banking institutions

In regards to this set of messages, the various situations that a banking institution is confronted to can be represented as follows:

With the following details:

A customer can request a fund transfer on his behalf using either a bank native channel (email, EBanking, branch, etc.) or by sending an MT101 to the bank. Big corporate customers can indeed be connected themselves to the bank network and send requests to the bank using the MT101 Message Type which is intended for this purpose.
Most of the time, the reception of an MT101 by the bank will make it issue an MT103 to proceed further with the Fund Transfers. But if the account to be debited is not by the bank, it can as well transfer the MT101 further to the other institution owning the account to be debited.
MT103 are sent following a customer request to transfer the funds further (serial method) or announce to the receiving institution that the funds will be coming following an MT202.COV (cover method).
An MT202 is sent on behalf of bank itself and not following a customer request, in contrary to MT103.
If the bank is a routing bank in the middle of a routing chain, MT103 and MT202 are sent further. Actually new messages are sent, the sent MT103 or MT202 can be different than the received one.

1.4 Serial and cover payments

SWIFT Serial and Cover payments originate from the two methods that are used to settle transactions in the SWIFT network and specifically in the field of correspondent banking: Serial method and Cover method.
When sender and receiver are located in different currency zones, they send or receive funds through their correspondents. And in this case, either of both methods can be used.

With the cover method, two different messages are initiated by the sender to settle the funds, an MT103 and an MT202.COV. The MT101 message is used to inform the creditor bank that funds are coming, it is an announcement. The MT202.COV, called cover message, moves the funds between correspondent accounts.
With the serial method, one single message is initiated by the sender to settle the funds, an MT103. That MT103 is in this case not an announce, but the fund transfer itself that moves for one party to the next in the payment chain until it reaches the beneficiary bank.

1.4.1 Cover method details

The MT103 announcement is sent to the beneficiary bank to announce that funds are coming for a specific beneficiary. It does not carry the funds but rather just informs the bank of the beneficiary that funds are coming for which beneficiary customer and which correspondent (of the beneficiary bank) will receive the funds.

The cover payment (MT202 COV) is sent by the sender to its correspondent. This is the message that really moves the funds. The MT202 COV enables the sender to ask its correspondent to debit its account (of the sender, with the correspondent) and credit the beneficiary bank's account with its correspondent.

Most of the time, the announcement is created and sent before the cover but that is not a requirement so receiving the cover payment before the announce is a situation that needs to be taken into account by the receiver.

1.4.2 Serial method details

Using an MT103, the funds moves from one party to another until it reaches the final beneficiary. Following a customer request, the sender sends an MT103 serial to its correspondent which transfers the funds to the intermediary institution. The intermediary institution is the correspondent of the beneficiary most of the time. The intermediary institution on its turn credits the account of the creditor bank and eventually the beneficiary account.

In the SWIFT MT103 Serial Message, the fields 56a and 57a are used while the fields 53a and 54a are used in the MT103 Announcement Message (cover method).
Intermediary institution and receiver's correspondent are usually two names to designate the same thing. The account with institution is the bank that holds the beneficiary account, so just another name for Creditor bank.

1.5 SWIFT Message Structure

This section presents how an ISO 15022 message looks like and decomposes it to its particular parts. The description of the structure is intended as a guidance to build a SWIFT message parser.

A message consists of blocks enclosed in curly braces. The first colon separates the block name and content. The block content can consist of sub-blocks.

Block Ident.	Block Name	Mandatory or Optional	Description	Comments
1	Basic Header	M	The only mandatory block is the basic header. The basic header contains the general information that identifies the message, and some additional control information. The FIN interface automatically builds the basic header.	Common to all SWIFT messages. It contains five fields that are all mandatory.
2	Application Header	O	The application header contains information that is specific to the application. The application header is required for messages that users, or the system and users, exchange. Exceptions are session establishment and session closure.	Common to all SWIFT messages. There are two variations: One block for input messages which may contain up to six fields and one for output messages which may have up to seven fields.
3	User Header	O	The user header is an optional header.	Common to all SWIFT messages. All fields of the user header (except the tag 103 for FINCopy Service) are optional. Fields are populated in specific situations.
4	Text	O	The text is the actual data to transfer.	This is the block found in the Message Reference Guide.
5	Trailers	O	The trailer either indicates special circumstances that relate to message handling or contains security information.	Common to all SWIFT messages. Like the block 3, this block consists of only non-mandatory fields except the checksum.

The various header blocks contain different kinds of information but not all of them are interesting for our use cases in my current company. The next chapters will present which field we extract and for what usage.

1.6 SWIFT BIC Code

The SWIFT BIC code is much more than an entity identifier. It is used to route the financial messages from the issuing institution to the receiving institutions. The SWIFT BIC Code therefore plays a crucial role in payment messaging. Without it, a message cannot be transported to the receiving entity over SWIFT Net.

The BIC code contains the identity and the location of the participants that are used to find out and reach the message destination.

The SWIFT BIC code is composed of exactly 8 or 11 alphanumeric characters structured as followed:

1.6.1 Structure of the SWIFT BIC Code

The structure of the BIC code is as follows:

alphabetical characters that indicate the identification of the institution (bank or corporate)
2 alphabetical characters for the ISO code of the country in which the institution is located
2 alphabetic or numeric characters used to locate the institution head office in the country or the head office in a particular region in the country.
- When the second character takes the value "0", it is typically a test BIC used in test systems as opposed to a BIC used on the live network (also production).
- When the second character takes the value "1", it denotes a passive participant in the SWIFT network. Passive participants cannot be contacted directly over the SWIFT Network. These BICs are sometimes referred to as ‘BIC1', ‘non-SWIFT BIC' and ‘non-connected BIC'. A non-connected BIC is not allowed in the header of a SWIFT message, otherwise the message is rejected by the SWIFT system.
- When second character takes the value "2", it indicates a reverse billing BIC, where the recipient pays for the message as opposed to the more usual mode where the sender pays for the message.
3 alphabetical or numeric characters to indicate a branch or agency of the institution. Unlike the first 8 characters, these last 3 are not mandatory. They are mainly used by banks and less by corporations.

Few examples to illustrate the above explanations:

DEUTDEFF is the BIC of Deutsche Bank (DEUT) / in Germany (DE) / Main office of Frankfurt (FF)
DEUTDESS is the BIC of Deutsche Bank (DEUT) / in Germany (DE) / Main office of Stuttgart (SS)
DEUTDESS648 is the BIC of Deutsche Bank (DEUT) / in Germany (DE) / Main office of Stuttgart (SS). 648 is the branch located in Vaihingen-Enz in the same region.
DEUTDES0 and DEUTDES0648 are test BIC for DEUTDESS and DEUTDESS648
LAFAFRPP is the BIC of Lafarge (LAFA) / in France (FF) / Main office of Paris (PP)

1.7 Other specific details

Below are some specific noteworthy details about SWIFT messages in a raw fashion:

Caution: about the little "a" in field names
Very often in documents and papers about SWIFT, fields are indicated with a little "a" as suffix, such as 54a, 56a, etc.
This lower case "a" needs not to be confused with the upper case "A" which indicates the variant of the field.
For instance, Field 50a exists in 3 variants: 50A, 50F, 50K. The little suffix "a" is just a convention to mention the field 50, it is not the indication of the variant "A"
About SWIFT Input and Output messages
In SWIFT, the notion of output and input related to the SWIFT network, not to the bank.
A SWIFT input message is an outbound message: a message emitted by the bank and send to another bank on the SWIFT network.
A SWIFT output message is an inbound message: a message received to a bank from the SWIFT network.
Qualifying messages as Input or Output is relative to the SWIFT network, i.e. inverse to the bank perspective (Input are messages sent by the bank, Output are messages received by the bank)

2. Dissecting key SWIFT Mesages involved in payments (Funds Transfers)

This chapter presents key SWIFT messages as well as some examples aimed at understanding the meaning and usage of most important SWIFT fields.

2.1 SWIFT MT101 Detailed Analysis

The SWIFT MT101 Request for Transfer is a payment initiation message used to send domestic and/or international payments instructions to their banks.

The situation of SWIFT MT101 in a banking institution is as follows:

Most of the time when the bank receives an MT101 it will either perform the operation if both debited and credited accounts are with itself, or it will issue an MT103 to proceed with the crediting of the destination account with another banking institution.

But there are situations as well where the account to be debited is not by the bank itself, in which case the MT101 can be routed further.

2.1.1 MT101 Introductory examples

This section presents various examples of SWIFT MT101 corresponding to different situations

2.1.1.1 MT101 Example 1: Simplest case

A corporate customer - Robert Corporation - of bank XYZ located in Switzerland wants to send 50k CHF to Vinino SARL in Geneva, another customer of bank XYZ. Robert Corporation being a big corporation, it is connected to the SWIFT network and trades on his account by the bank using SWIFT MT 101 messages.

In this situation, there is no SWIFT messages emitted further whatsoever since both customers are customer of bank XYZ.

Details of the MT101:

There is one single transaction in this MT101.
Both accounts are with bank XYZ so no Account with Institution or Account Servicing Institution need to be indicated.

2.1.1.2 MT101 Example 2: beneficiary with another institution

A corporate customer - Robert Corporation - of bank XYZ located in Switzerland wants to send 500k EUR to Dupont SARL in Paris.
The corporation Dupont SARL is not a customer of bank XYZ, it is a customer of bank BNP Parisbas in Paris.
Bank XYZ and BNP Paribas have a direct banking relationship.

Since Bank XYZ and BNP Paribas have a direct banking relationship, Bank XYZ can send an MT103 to BNP Paribas to make it credit the customer account from its VOSTRO account by BNP Paribas.

Details of the MT101:

There is one single transaction in this MT101.
The beneficiary account to be credit is not by bank XYZ, so the eventual banking institution the funds need to be sent to is indicated in Account With Institution - 57A.

2.1.1.3 MT101 Example 3: Multiple payments in MT101

In this third example, Corporation Robert Corp of bank XYZ located in Switzerland wants to send a first payment of 100k EUR to Dupont Sarl in Paris and a second payment of 200 K to Jacob SA in France.
Dupont Sarl is a customer of Bank BNP Paribas in Paris and Jacob SA is a customer of bank Credit Agricole in France as well.

Bank XYZ in Switzerland and BNP Paribas Paris have a direct banking relationship, and BNP Paribas and Credit Agricole have a direct banking relationship as well.

He wants to use different accounts for both transactions and he is submitting both transactions in the very same MT101.

The MT101 makes it possible to input as many transaction in a single message, having at least one occurrence of the repetitive sequence is mandatory.

Since Credit Agricole and Bank XYZ have no direct banking relationship, the second transaction, crediting Jacob SA has to go through BNP Paribas as well.

Details of the MT101:

This MT101 contains two distinct transactions
In both case Account with Institution - field 57A - identifies the eventual destination of the funds for both transactions
The ordering customer - field 50H - is the same from a customer perspective but the accounts used for both fund transfers are different. For this reason the ordering customer is indicated in the repetitive sequence, not in sequence A.

2.1.1.4 MT101 Example 4: Payment from a subsidiary account

A parent company can also use the SWIFT MT101 to pay from own account on behalf of multiple subsidiaries.

In this example, the parent company Robert Corp located in Switzerland has received an invoice from Jacob SA for various services that Jacob SA provided to the local company Robert Corp France SARL, a subsidiary of Robert Corp located in France.

The parent company Robert Corp decides to use the account of the subsidiary company in France to pay for the invoice (there can be various reasons for that).
The subsidiary has granted permission to the parent company for trading with its account with BNP Paris.

The trick here is in the field 50a Instructing Party. In the SWIFT standard we read the following under the usage rules of that field: "This field must only be used when the instructing customer is not also the account owner."
The field 50a Instructing Party specifies the subsidiary company - FR12983459182931 / Robert Corp France Sarl - on behalf of which the parent company, RBCPCHAA02A, sends the payment instruction.

Details of the MT101:

Account Servicing Institution - field 52A - is identifying the fact that the MT101 needs to be transferred further to the institution owning the account of the subsidiary where the funds need to be debited from: BNP Paris / BNPSFRZA93B.
The Account with institution - field 57A - is identifying the eventual recipient of the funds, the institution owning the account to be credited: Bank Credit Agricole / CACIFRXA12C.
Instructing Party - field 50L - identifies that the parent corporation is actually the one at the origin of this MT101, acting on behalf of the ordering customer - 50 H - the subsidiary in France.

2.1.1.5 MT101 Example 5: Fund repatriation

There is another possibility: funds repatriation.
Funds repatriation simply means to move the funds available on one account to another account held either by the same financial institution or by another financial institution. Funds repatriation is performed for cash pooling inside a company or a group of companies. Corporations resort to cash pooling to optimize the liquidity usage.

In this example, Robert Corp (a corporate customer) has an account by bank XYZ in Switzerland and an account by bank BNP Paribas Paris which he uses for his operations in EUR.
Robert Corp. wants to repatriate all the funds he has on his BNP Paris account back to his Bank XYZ Account.
Bank XYZ account is called centralized account, master account or leader account. The BNP Paris account is called secondary account or slave account.

In this case the MT101 is transmitted further to the bank owning the debited account and the funds are repatriated with the MT103.

Details of the MT101:

Account Servicing Institution - field 52A - is identifying the fact that the MT101 needs to be transferred further to the institution owning the account: BNP Paris / BNPSFRZA93B.
The Account with institution - field 57A - is identifying the eventual recipient of the funds, the institution owning the account to be credited: Bank XYZ / BXYZCHZZ80A.
Using the instruction code - field 23 - CMZB - Code to Zero Balance, it is not necessary to specify any amount, the code will be balanced down to zero and all the available funds repatriated.

2.1.2 MT101 Parsing and Data Mapping

The MT101 parsing details are presented in the table below. Only most essential fields are discussed.

Meaning	SWIFT		Example	Comment
	Field	Variant
AppID	Block1/ApplId		F	The Application Identifier identifies the application within which the message is being sent or received. The available options are: F = FIN , A = GPA, etc. These values are automatically assigned by the SWIFT system and the user's CBT
ServiceID	Block1/Servid		01	The Service Identifier consists of two numeric characters. It identifies the type of data that is being sent or received and, in doing so, the type of the following message
Sender (Sending bank / BIC)	Block1/ LTaddrBlk1 (I) Or Block2/ LTaddrBlk2 (O)		SGOBFRPP	Sender BIC appears in header block (Block 1) in the MT101 Input and in the application block (Block 2) in the MT101 Output (Input and output related to the SWIFT network, not the bank). Need to use field Block2 / Inoutind to find out
Message Type	Block2/ Msgtype		101	SWIFT Message Type = MT 101
Receiver (Receiving Bank / BIC)	Block2/ LTaddrBlk21 (I) Or Block1/ LTaddrBlk1 (O)		RBOSGB2L	The Receiver BIC appears in header block (Block1) in the MT101 Output and in the application block (Block 2) in the MT101 Input. (Input and output related to the SWIFT network, not the bank). Need to use field Block2 / Inoutind to find out. The receiver of the message is the eventual beneficiary only if no field 57 says otherwise.
Sender's Reference	20		ORDERREF1234	This field is mandatory and of format 16x. It is a reference assigned by the Sender to unambiguously identify the message.
Customer Specified Reference	21	R	GBSUPPLIERS5668	The field is optional and of format 16x. It is a reference to the entire message assigned by either the instructing party, when present or by the ordering customer, when the instructing party is not present.
Message Index/Total	28	D	1/1	It is mandatory and of format : 5n/5n for (Message Index)/(Total) If you send 5 messages for the same order, this field will take the value 1/5 in the first message, 2/5 in the second message, and so on. 1/1 means there is only one message sent for this order.
Sender Msg. Sending Timestamp	(O) Block2 / ‘ Intime + Inmate (I) System.time()		1538070522	(O) = Output only : SWIFT timestamp for an Output message (HHMMYYMMDD) or local date/time for an Input Message.
In / Out-put flag	Block2 / Inoutind		I	Single letter ‘I' or ‘O'
Ordering Customer	50	F	/DE20700800000... 1/Essilor International 2/147 Rue de Paris 3/FR/Charenton 94220	Line 1 (subfield Party Identifier) /34x (Account) Lines 2-5 : (Number/Name and Address) 1!n/33x (Number)(Details)	The field ordering customer is mandatory. In can be given either in the message details (here) or per transaction in the repeating sequence
		G	/31926819 UBSCH123FNX	Line 1 (subfield Party Identifier) /34x (account) Line 2 (subfield bank) BIC (8 or 11 characters)
		H	/31926819 Compagnie de Saint Gobain 118 Rue Lauriston 75016 Paris	Line 1 (subfield Party Identifier) /34x (Account) Lines 2-5 : (Number/Name and Address) 4*35x (Name and Address)
Authorization	25		12DF64BG345A	Optional, 35x (authorization code)
Requested Execution Date	30		181017	The value date, mandatory and of format 6!n (YYMMDD). It is the date on which all subsequent transactions should be initiated by the executing bank.
Repeating Sequence
Transaction Reference	21		35863REFOFTRX1	This field is mandatory and of format 16x. It is a reference assigned by the Sender to unambiguously identify a unique transaction.
F/X Deal Reference	21	F	FXDEALID78685	Optional, if there is an underlying foreign exchange deal to this transaction, then this field specifies the FX deal reference
Instruction Code	23	E	CMZB (= Code to Zero balance the account. This transaction contains a cash Management instruction, requesting to zero balance the account of the ordering customer) INTC =( Code for Intra-Company Payment.)	It is optional and of format :4!c[/30x] (Instruction Code)(Additional Info.) Optional instruction codes that identifies the operation types. Caution : there can be several instruction codes (all with same code) in the SWIFT message.
Charges Account	25	A	/FR763000402837...	This is the ordering customer's account number to which applicable transaction charges should be separately applied by the debtor.
Currency, Transaction Amount	32	B	GBP50000	Mandatory and of Format 3!a15d (Currency)(Amount)
Currency, Original Ordered Amount	33	B	EUR200000	This optional field is provided in format 3!a15d. It specifies the original currency and amount as specified by the ordering customer.
Exchange Rate	36		1,1382	Mandatory since field 33B is present and 'amount' in field 32B is not equal to zero. Provided in format 12d. The integer part of Rate must contain at least one digit. A decimal comma is mandatory and is included in the maximum length.
Instructing Party	50	L	Compagnie de Saint Gobain 118 Rue Lauriston 75016 Paris	This field is optional and to be provided if the sending customer (instructing party) is different than the owner of the account (but has an authorization to make payment on account given by owner) Compagnie de Saint Gobain instructs the payment but does not own the account to be debited. It is authorized by it's the owner (e.g. a subsidiary) to pay form the ordering customer account provided below.
Ordering Customer	50	F	/DE207008000... 1/Essilor International 2/147 Rue de Paris 3/FR/Charenton 94220	Line 1 (subfield Party Identifier) /34x (Account) Lines 2-5 : (Number/Name and Address) 1!n/33x (Number)(Details)	The field ordering customer is mandatory. In can be given either in the message details or per transaction in the repeating sequence (here)
		G	/31926819 UBSCH123FNX	Line 1 (subfield Party Identifier) /34x (account) Line 2 (subfield bank) BIC (8 or 11 characters)
		H	/31926819 Compagnie de Saint Gobain 118 Rue Lauriston 75016 Paris	Line 1 (subfield Party Identifier) /34x (Account) Lines 2-5 : (Number/Name and Address) 4*35x (Name and Address)
Account Servicing Institution	52	A	//083098 (BSB) NATAAU33 (bic)	This is to notify the receiving bank that the institution owning the account to debit is another institution So the MT101 needs to be transferred to that other institution identified here. The BSB (Bank State Branch) code and the BIC are provided. Even if it is not mandatory in the SWIFT standards to use the BSB code preceded by a double slash. Many banks impose it. We need to parse the BIC out of it Format : &bnsp;&bnsp;&bnsp;&bnsp;[/1!a][/34x] (Party Identifier) &bnsp;&bnsp;&bnsp;&bnsp;4!a2!a2!c[3!c] (Identifier Code)
Intermediary Institution	56	A	PNBPUS3N (bic)	This is the Correspondent of the Creditor Bank. It holds the account in currency of the creditor bank. It is optional and can be provided in option A, C or D. Formats C or D are rarely used and most of the time not supported by banks. Option A is formatted [/1!a][/34x] (Party Identifier) 4!a2!a2!c[3!c] (Identifier Code / BIC)
Account With Institution	57	A	BARCGB22XXX (bic) or e.g. //939400 (BSB) AMPBAU2SXXX (bic)	We need to parse the BIC out of it Format : [/1!a][/34x] (Party Identifier ) 4!a2!a2!c[3!c] (Identifier Code)	Optional. The Account with Institution is provided because the beneficiary does not have an account with the debtor bank, but with another bank .(i.e. an MT103 will be sent further) It can be provided in option A, B, C or D. Formats B, C are rarely used and most of the time not supported by banks. For instance, in case the Creditor bank is not the same as the debtor bank (most of the time), it is identified in field 57a. The BSB (Bank State Branch) code and the BIC of AMP Bank are provided. We need to parse the BIC out of it or hash the address (priority over header)
		D	Hong Kong Banking Assoc. Avenue du Léman 1204 Genève - CH Switzerland	If no BIC is available to identify the target institution, option D is used. In principle minimum 3 lines with name and address should be provided Format: [/1!a][/34x] (Party Identifier) 4*35x (Name and Address) In this case, take country from receiver BIC
Beneficiary	59	(no letter)	/26351-38947 Company One CITY STREET 50 LONDON, UK	Line 1 : [/34x] (Account) IBAN format or else Line 2-5: 4*35x (Name and Address)	Beneficiary customer information is Mandatory
		A	NBPUS3N or e.g. /12345678901 PNBPUS3N	Option A is formatted [/1!a][/34x] (Party Identifier) 4!a2!a2!c[3!c] (Identifier Code / BIC)
		F	/10078074 1/Company One 2/CITY STREET 50 3/GB/LONDON	Line 1 (subfield Party Identifier) [/34x] (Account) Lines 2-5 : (Number/Name and Address) 4*(1!n/33x) (name and address)
Remittance Information	70		Payment from Compagnie de Saint Gobain /INV/7828728292	Remittance information is optional and provided in format 4*35x if available. Up to 4 lines of up to 35 X characters each. The name of the parent company is provided here, so that the beneficiary can see it is the parent company that is paying.
Details of Charges	71	A	OUR	It is mandatory and of format 3!a. It can take 3 values: BEN, OUR and SHA. OUR means charges are to be borne by the ordering customer. SHA means charges are shared between Ordering and beneficiary customers. BEN means charges are to be borne by the beneficiary

2.1.3 Additional notes on MT101

Some complementary notes:

MT 101 have a repeating sequence (several transactions in same message). In my currently company, we consider every repeating sequence B (repeating) as a different transaction. The common sequence (A) is duplicated for each.
We still need a way identify uniquely a message. Unfortunately SWIFT doesn't have such thing as a unique transaction identified. We usually use as "business_reference" = [Transaction Reference / 21 / transaction_business_reference] concatenated to a UUID as suffix.
What to do in case of 57D if we cannot find a country code? One way is to use the SWIFT message Receiver BIC country (sometimes wrong but better than nothing, only sometimes since when 57D is used we are likely in the same country

2.2 SWIFT MT103 Detailed Analysis

The MT103 is a SWIFT message format used for making payments. MT103 SWIFT payments are known as international wire transfers, telegraphic transfers, standard EU payments (SEPA payments), LVTS in Canada, etc.

The situation of SWIFT MT103 in a banking institution is as follows:

There can be many different situations:

An MT103 can be sent after a request from a customer of the bank to send funds cross-border to another institution. The customer request can come from any channel including the reception of an MT101.
The MT103 can be a routed message in case the bank is simply a routing bank in the chain or an explicit intermediary institution.
Then MT103 can be simple announces - in the cover method - or actual funds transfers - in the serial method.

2.2.1 MT103 Introductory examples

This section presents various examples of SWIFT MT101 corresponding to different situations

2.2.1.1 MT103 Example 1: Simplest case

In this example, the customer "John Robert" of bank XYZ in Switzerland wants to send 500k EUR to Dupont SARL, a corporation located in Paris which is a BNP Paribas customer.

Bank XYZ and BNP Paribas have a direct banking relationship.

A single MT103 is sufficient to implement the fund transfer.

2.2.1.2 MT103 Example 2: more realistic example

This example is a more realistic example. The previous one is from a pure SWIFT specification perspective entirely valid. But in practice, a few more fields are almost always present in a SWIFT message.

This example is more or less the same as the previous one: the customer "John Robert" of bank XYZ in Switzerland wants to send 30k EUR to Dupont SARL, a corporation located in Paris which is a BNP Paribas customer.
Bank XYZ and BNP Paribas have a direct banking relationship.

The first thing is that Bank XYZ obviously has several VOSTRO account by BNP Paribas, and it wants to choose which of these accounts it wants to use for the reimbursement. It wants to use account 12345678901.

The field 53 normally indicates the Sender's correspondent (i.e. a banking institution), but it's common practice to use the variant 53B to indicate the account by the receiving institution to be used for the reimbursement.

In addition, in this more realistic example the charges details are indicated as well as remittance information.

2.2.1.3 MT103 Example3: forwarded serial message

In the case the bank we are operating within is neither the ordering institution (initial sender) neither the eventual beneficiary institution, it is just a routing bank. In this case, specific fields are used to identify the initial sending institution as well as the eventual beneficiary institution. These fields are illustrated in this example.

In this example, customer Max Prank of bank BCVs in Switzerland wants to send 30k EUR to Alfred SARL in Samoens (France), a customer of "Banque Populaire" in France.
BCVs in Switzerland and Banque Populaire in France have no direct relationship together so the fund transfer has to go through several routing bank, one of them being bank XYZ.

We are here interested in the MT 103 sent by Banque XYZ, a routing bank to the next bank in the routing chain: BNP Paribas.

Since bank XYZ is not the initial sending institution, and the receiver of the SWIFT message, bank BNP Paribas is not the eventual beneficiary institution, these two other institutions (initial sending and eventual beneficiary) needs to be indicated in the SWIFT messages.

Details of the SWIFT MT103:

The field Ordering institution - field 52A - is clearly identifying the initial sending institution, bank BCVs
The field Account with institution - field 57A - is clearly identifying the eventual beneficiary institution of the funds

It is relevant to look at the two other SWIFT messages from the chain to be able to compare them:

Another noteworthy field is the field Intermediary account - field 56A - which identified that the message has to go through BNP Paribas after Bank XYZ.

2.2.1.4 MT103 Example 4: Announce message (cover method)

We'll now go through a case where the MT103 is just an announce as part of the cover payment method. This is the case when the initial sending institution and the eventual beneficiary institution have no relationship together and decide to go through their correspondent.

In case the MT103 is just an announce, it can be sent directly from the initial sending institution to the eventual beneficiary institution regardless of the fact that they have no banking relationship with each other.

In this example, the customer John Trump of bank XYZ in Switzerland wants to send 1'000'000 USD to Cowboy Corp. in Kensas City, a customer of "Kensas Credit"
Due to the nature of the transaction and their missing banking relationship together, they decide to go through correspondent banks :

An MT103 is sent directly to the beneficiary bank, regardless of the fact they have no banking relationship together
An MT202.COV will be routed through correspondent(s) and routing banks

We are here interested in the MT 103 sent by Bank XYZ, the announcement, which can be sent directly to beneficiary bank

The MT103 announce clearly indicates that the fund transfer will go through correspondents with the usage of the fields Sender's correspondent - field 53A - and Receiver's Correspondent - field 54A.
Aside from this, there is no specific difference between this announce and a serial MT103 fund transfer.

2.2.2 MT103 Parsing and Data Mapping

The MT103 parsing details are presented in the table below. Only most essential fields are discussed.

Meaning	SWIFT		Example	Comment
	Field	Variant
AppID	Block1/ApplId		F	The Application Identifier identifies the application within which the message is being sent or received. The available options are: F = FIN , A = GPA, etc. These values are automatically assigned by the SWIFT system and the user's CBT.
ServiceID	Block1/Servid		01	The Service Identifier consists of two numeric characters. It identifies the type of data that is being sent or received and, in doing so, the type of the following message
Sender (Sending bank / BIC)	Block1/ LTaddrBlk1 (I) Or Block2/ LTaddrBlk2 (O)		SGOBFRPP	Sender BIC appears in header block (Block 1) in the MT103 Input and in the application block (Block 2) in the MT103 Output (Input and output related to the SWIFT network, not the bank). Need to use field Block2 / Inoutind to find out
Message Type	Block2/ Msgtype		103	SWIFT Message Type = MT 103
Cover or Serial Transfer Type			If field 56a or 57a are present : then transfer type = "serial" If field 53a (ex 53B) or 54a are present : then transfer type = "announce (cover)" (Default : serial)	Knowing whether the MT103 is a serial transfer or the announce preceding a cover transfer is important. For a given use case, we actually expect a banking institution always to use the very same method.
Receiver (Receiving Bank / BIC)	Block2/ LTaddrBlk2(I) Or Block1/ LTaddrBlk1 (O)		RBOSGB2L	The Receiver BIC appears in header block (Block1) in the MT103 Output and in the application block (Block 2) in the MT103 Input. (Input and output related to the SWIFT network, not the bank). Need to use field Block2 / Inoutind to find out. The receiver of the message is the eventual beneficiary only if no field 57 says otherwise.
Unique End-to-end Transaction Reference	Block3/ Tag 121		b03c6901-bbed-4aa9-afdh-A5bc26d19257	This reference is provided in the user block (Block 3) and transported end-to-end. It is mandatory in MT103 but can still be missing as well as have duplicates.
Sender's Reference	20		ORDERREF1234	This field is mandatory and of format 16x. It is a reference assigned by the Sender to unambiguously identify the message.
Sender Msg. Sending Timestamp	(O) Block2 / ‘ Intime + Indate (I) Sys.time()		1538070522	(O) = Output only : SWIFT timestamp for an Output message (HHMMYYMMDD) or local date/time for an Input Message.
In / Out-put flag	Block2 / Inoutind		I	Single letter ‘I' or ‘O'
Bank operation code	23	B	CRED	It is mandatory and of format 4!c.
Instruction code	23	E	PHOB/+34.91.397.6789	It is optional and of format :4!c[/30x] (Instruction Code)(Additional Info.) Code PHOB means Phone Benef.. The sender requests the benef. bank to contact benef. by phone when funds are received.
Value Date / currency / interbank settled amount	32	A	180816USD2325,	It is mandatory and of format 6!n3!a15d (Date)(Currency)(Amount). Note the trailing coma (i.e. decimal part is not mandatory if 0)
Currency / Instructed Amount	33	B	USD2350,	Normally optional in the standard. It may be provided for instance because the sender has taken fees. See field 71F below. Format 3!a15d (Currency)(Amount)
Ordering Customer	50	A	/DE3750070010... DEUTDEFF	Line 1 (subfield Party Identifier) /34x (account) Line 2 (subfield bank) 4!a2!a2!c[3!c] (Identifier Code)	The field ordering customer is mandatory. In can be given either in the message details (here) or per transaction in the repeating sequence. The ordering customer is customer of the sender only if there is no field 52. The ordering customer remains constant in the message chain.
		F	/DE207008000... 1/Essilor International 2/147 Rue de Paris 3/FR/Charenton-le-Pont, 94220	Line 1 (subfield Party Identifier) /34x (Account) Lines 2-5 : (Number/Name and Address) 1!n/33x (Number)(Details)
		K	/CH570483509... GALLMAN COMPANY GMBH RAEMISTRASSE, 71 8006 ZURICH SWITZERLAND	Line 1 : (subfield party identified) /34x (Account) Line 2-5 (subfield Address) 4*35x (Name and Address)
Ordering institution	52	A	BNPAFRPP or e.g. /FR123509321... BNPAFRPP	Format [/1!a][/34x] (Party Identifier) 4!a2!a2!c[3!c] (Identifier Code)	Ordering institution is optional and can be provided in two options A (usual) and D (less common). The sender populates this field to indicate that the initial instruction comes from another institution (ordering institution). The ordering institution remains constant in the message chain. (priority over header)
		D	BANQUE DELUBAC ET CIE 16 PL SALEON TERRAS 07160 LE CHEYLARD	Format [/1!a][/34x] (Party Identifier) 4*35x (Name and Address)
Sender's correspondent	53	A	PNBPUS3N or e.g. /12345678901 PNBPUS3N	Cover payments only Correspondent of sender. Sender has an account in Currency with this banking institution. Option A is formatted [/1!a][/34x] (Party Identifier) 4!a2!a2!c[3!c] (Identifier Code / BIC)
		B	/12345678901	Caution : Serial and cover payments. Field 53B indicates the account number of the Sender, serviced by the Receiver, which is to be used for reimbursement (debit) in the transfer. This the account of the sender by the receiver (VOSTRO) Option B Format is: [/1!a][/34x] (Party Identifier) [35x] (Location) The field is optional but In practice, the account number is almost always provided.
Receiver's correspondent	54	A	IRVTUS3N or e.g. /9876412-1234/123 IRVTUS3N	Cover payments only. Correspondent of receiver. Receiver has an account in currency with this banking institution. Option A is formatted [/1!a][/34x] (Party Identifier) 4!a2!a2!c[3!c] (Identifier Code / BIC)
Intermediary Institution	56	A	IRVTUS3N (bic) or e.g. /939400 (BSB or account) AMPBAU2SXXX (bic)	Serial payments only. This is the Correspondent of Creditor Bank. It holds the account in currency of the creditor bank. It is used instead of over 54a (Receiver's Correspondent) in case of a serial payment transfer. It is optional and can be provided in option A, C or D. Formats C or D are rarely used and most of the time not supported by banks. Option A is formatted [/1!a][/34x] (Party Identifier) 4!a2!a2!c[3!c] (Identifier Code / BIC)
Account With Institution	57	A	BARCGB22XXX (bic) or e.g. //939400 (BSB) AMPBAU2SXXX (bic)	We need to parse the BIC out of it Format : [/1!a][/34x] (Party Identifier ) 4!a2!a2!c[3!c] (Identifier Code)	Serial payments only. Account with institution is optional and can be provided in option A, B, C or D. Formats B, C are rarely used and most of the time not supported by banks. Field 57 is used when the receiver of the SWIFT MT103 doesn't own the beneficiary account and needs to send the Message Further. In the final MT103 on the chain, the holder of the account will be the receiver and no field 57 will be required anymore. We need to parse the BIC out of it or hash the address (priority over header)
		D	Hong Kong Banking Assoc. Avenue du Léman 1204 Genève - CH Switzerland	If no BIC is available to identify the target institution, option D is used. In principle minimum 3 lines with name and address should be provided Format : [/1!a][/34x] (Party Identifier ) 4*35x (Name and Address) In this case, take country from receiver BIC.
Beneficiary	59	(no letter)	/26351-38947 Company One CITY STREET 50 LONDON, UK	Line 1 : [/34x] (Account) (IBAN format or else) Line 2-5: 4*35x (Name and Address)	Beneficiary customer information is Mandatory. The beneficiary remains constant in the message chain.
		A	PNBPUS3N or e.g. /12345678901 PNBPUS3N	Option A is formatted [/1!a][/34x] (Party Identifier) 4!a2!a2!c[3!c] (Identifier Code / BIC)
		F	/10078074 1/Company One 2/CITY STREET 50 3/GB/LONDON	Line 1 (subfield Party Identifier) [/34x] (Account) Lines 2-5 : (Number/Name and Address) 4*(1!n/33x) (name and address)
Remittance Information	70		/INV/18042-090715	Remittance information is optional and provided in format 4*35x if available. Up to 4 lines of up to 35 X characters each. Usually the remittance information is generated by the beneficiary and sent to the ordering customer (or debtor). The beneficiary requests the debtor to provide it the payment message, so that the beneficiary can easily reconcile the payment with an invoice for instance.
Details of Charges	71	A	OUR	It is mandatory and of format 3!a. It can take 3 values: BEN, OUR and SHA. OUR means charges are to be borne by the ordering customer. SHA means charges are shared between Ordering and beneficiary customers. BEN means charges are to be borne by the beneficiary
Sender's charges	71	F	EUR2,50	Optional. When 71A is BEN (or SHA), 71G contains amount of the charges due, which have been deducted from the interbank settlement amount. Interbank settled amount = Instructed amount - Sender's charges. Format 3!a15d Caution: there can be several different 71F in a same MT103.
Receiver's charges	71	G	EUR2,50	Optional. When 71A is OUR (or SHA), 71G contains amount of the charges due, which have been prepaid and included in the interbank settlement amount. Format 3!a15d Caution : there can be several different 71G in a same MT103.
Sender to Receiver Information	72		/INS/BNPAFRPP	This is an optional field. It takes the Format 6*35x. There can be many codes indicating additional information. INS is a code indicating that BNPAFRPP is the instructing institution. Without field 72, the receiver may not know it since that information is not provided somewhere else in the message when sender is the next bank on the routing chain and ordering institution is another bank before the instructing one.

2.2.3 Additional notes on MT103

Some complementary notes:

The option field 53B (only variant B) is really only used to indicate which account at the correspondent (receiver) should be debited.
Fields 51A seems to be not supported by most banks (at least all I found such as UBS, etc.)
When no correspondent is used neither on sender side (Tag 53A) nor on receiver side (Tag 54A) and No reimbursement party (Tags 56a and 57a) is indicated in the SWIFT MT103 message. It means
- there is a direct account relationship, in the currency of the transfer, between the Sender and the Receiver. Money will be taken from account and credited to the beneficiary.
- Beneficiary customer account (:59) is hold by the receiver.
The fields 56a and 57a are used for serial transfers while the fields 53a (ex 53B) and 54a are used in the MT103 Announcement Message (cover method).
What to do in case of 57D if we cannot find a country code? We Use SWIFT message Receiver BIC country (sometimes wrong but better than nothing, only sometimes since when 57D is used we are likely in the same country)
Routing
- When there is no ordering institution (Tag 52) in the SWIFT MT103 message. That means implicitly that the ordering customer is customer of the Sender.
- When the ordering institution (Tag 52D) is provided in the MT103 SWIFT Message. This means the ordering customer is not customer of the Sender.
Field 57 is used when the receiver of the SWIFT MT103 doesn't own the beneficiary account and needs to send the Message Further.
In the final MT103 on the chain, the holder of the account will be the receiver and no field 57 will be required anymore.
- This indicates that Sender and Beneficiary customer's Bank do not have direct account relationship in the currency of the transaction (USD). Otherwise the sender would send the message directly to the beneficiary customer's Bank.
Sender's reference is new for every message in the routing chain, but end-to-end reference remains constant.

2.3 SWIFT MT202 Detailed Analysis

SWIFT MT202 Messages are used for interbank funds transfers. There is no customer involved when issuing an MT202. Funds are not sent on behalf of a customer but on behalf of the initial sending banking institution itself.

The situation of SWIFT MT202 in a banking institution is as follows:

There can be two different situations:

Either the bank is the initial sending institution, in which case it will be identified both as the sender of the SWIFT message and perhaps as the Ordering Institution (52a)
Or the bank is just a routing bank in the routing chain in which case it is the sender but shall be different that the Ordering Institution (52a)

2.3.1 SWIFT MT202 Introductory Exampkes

This section presents various examples of SWIFT MT202 corresponding to different situations

2.3.1.1 MT202 Example 1: simplest case

In this first example, bank XYZ wants to send 1 million euros from its general VOSTRO account 1234-5678 by BNP Paribas to another of its own account FR982381827331 also by BNP Paribas.
The field "Receiver's Correspondent" - 53B - is diverted for the usage of identifying the source account to use for debit.

Details of the SWIFT MT202:

The beneficiary institution is a field that doesn't exist in MT103 and introduced by MT202. It does not identify the eventual institution owning the account to be credited but the Banking institution owning that account, actually the bank being the customer of the institution owning its correspondent account.

2.3.1.2 MT202 Example 2: other bank case

In this second example, bank XYZ wants to send 1 million euros from its general VOSTRO account 1234-5678 by BNP Paribas to an account belonging to another financial institution: Banque Populaire in France. This other banking institution also owns an account by BNP Paribas.
The account of Banque Populaire by BNP Paribas is FR98238182733.

The field "Receiver's Correspondent" - 53B - is diverted for the usage of identifying the source account to use for debit.

The details of this SWIFT MT 202 are fundamentally similar to the one from the previous example:

The field Beneficiary Institution - 58A - identifies clearly the eventual beneficiary institution owning the account by the Account with Institution - field 57A, in this case Banque Populaire.

2.3.1.3 MT202 Example 3: routed message

In this example we’ll see how a routed MT202 looks like. In this example, bank BCVs wants to send money to Banque Populaire. They are not using correspondent, the initial account debited is by BCVs and the eventual beneficiary account is by Banque Populaire.

Since BCVs and Banque Populaire have no relationship together, the MT202 needs to be routed through banks having a banking relationship. In this example we look at the MT202 forwarded by bank XYZ, one of the bank on the routing chain.

Details of this SWIFT MT202 message:

The field account with Institution - 57A has the same value than the field beneficiary institution - 58A - since the funds make it to Banque Populaire.

2.3.2 MT202 Parsing and Data Mapping

The MT202 parsing details are presented in the table below. Only most essential fields are discussed.

Meaning	SWIFT		Example	Comment
	Field	Variant
AppID	Block1/ApplId		F	The Application Identifier identifies the application within which the message is being sent or received. The available options are: F = FIN , A = GPA, etc. These values are automatically assigned by the SWIFT system and the user's CBT.
ServiceID	Block1/Servid		01	The Service Identifier consists of two numeric characters. It identifies the type of data that is being sent or received and, in doing so, the type of the following message
Sender (Sending bank / BIC)	Block1/ LTaddrBlk1 (I) Or Block2/ LTaddrBlk2 (O)		SGOBFRPP	Sender BIC appears in header block (Block 1) in the MT202 Input and in the application block (Block 2) in the MT202 Output (Input and output related to the SWIFT network, not the bank). Need to use field Block2 / Inoutind to find out
Message Type	Block2/ Msgtype		202	SWIFT Message Type = MT 202
Validation Flag	Block3/Tag119		COV (if MT202 is a cover payment)	This validation flag is provided the user block (Block 3) and transported end-to-end. It indicates that the message is a MT202 Cover.
Receiver (Receiving Bank / BIC)	Block2/ LTaddrBlk2(I) Or Block1/ LTaddrBlk1 (O)		RBOSGB2L	The Receiver BIC appears in header block (Block1) in the MT292 Output and in the application block (Block 2) in the MT202 Input. (Input and output related to the SWIFT network, not the bank). Need to use field Block2 / Inoutind to find out. The receiver of the message is the eventual beneficiary only if no field 57 says otherwise.
Unique End-to-end Transaction Reference	Block3/ Tag 121		b03c6901-bbed-4aa9-afdh-A5bc26d19257	This reference is provided in the user block (Block 3) and transported end-to-end. It is mandatory in MT103 but can still be missing as well as have duplicates.
Sequence A - General Information (Matching MT 202 format)
Sender's Reference	20		ORDERREF1234	This field is mandatory and of format 16x. It is a reference assigned by the Sender to unambiguously identify the message.
Related reference	21		123456789ABCDEF	This field is mandatory and of format 16x.
Sender Msg. Sending Timestamp	(O) Block2 / ‘ Intime + Indate (I) Sys.time()		1538070522	(O) = Output only : SWIFT timestamp for an Output message (HHMMYYMMDD) or local date/time for an Input Message.
In / Out-put flag	Block2 / Inoutind		I	Single letter ‘I’ or ‘O’
Value Date / currency / interbank settled amount	32	A	180816USD2325,	It is mandatory and of format 6!n3!a15d (Date)(Currency)(Amount). Note the trailing coma (i.e. decimal part is not mandatory if 0)
Ordering institution	52	A	BNPAFRPP or e.g. /FR123509321... BNPAFRPP	Format [/1!a][/34x] (Party Identifier) 4!a2!a2!c[3!c] (Identifier Code)	Ordering institution is optional and can be provided in two options A (usual) and D (less common). The sender populate this field to indicate that the initial instruction comes from another institution (ordering institution). The ordering institution remains constant in the message chain. (priority over header)
		D	BANQUE DELUBAC ET CIE 16 PL SALEON TERRAS 07160 LE CHEYLARD	Format [/1!a][/34x] (Party Identifier) 4*35x (Name and Address)
Sender's correspondent	53	A	PNBPUS3N or e.g. /12345678901 PNBPUS3N	Cover payments only Correspondent of sender. Sender has an account in Currency with this banking institution. Option A is formatted [/1!a][/34x] (Party Identifier) 4!a2!a2!c[3!c] (Identifier Code / BIC)
		B	/12345678901	Caution : Serial and cover payments. Field 53B indicates the account number of the Sender, serviced by the Receiver, which is to be used for reimbursement (debit) in the transfer. This the account of the sender by the receiver (VOSTRO) Option B Format is: [/1!a][/34x] (Party Identifier) [35x] (Location) The field is optional but In practice, the account number is almost always provided.
Receiver’s correspondent	54	A	IRVTUS3N or e.g. /9876412-1234/123 IRVTUS3N	Cover payments only. Correspondent of receiver. Receiver has an account in currency with this banking institution. Option A is formatted [/1!a][/34x] (Party Identifier) 4!a2!a2!c[3!c] (Identifier Code / BIC)
Intermediary Institution	56	A	IRVTUS3N (bic) or e.g. /939400 (BSB or account) AMPBAU2SXXX (bic)	Serial payments only. This is the Correspondent of Creditor Bank. It holds the account in currency of the creditor bank. It is used instead of over 54a (Receiver's Correspondent) in case of a serial payment transfer. It is optional and can be provided in option A, C or D. Formats C or D are rarely used and most of the time not supported by banks. Option A is formatted [/1!a][/34x] (Party Identifier) 4!a2!a2!c[3!c] (Identifier Code / BIC)
Account With Institution	57	A	BARCGB22XXX (bic) or e.g. //939400 (BSB) AMPBAU2SXXX (bic)	We need to parse the BIC out of it Format : [/1!a][/34x] (Party Identifier ) 4!a2!a2!c[3!c] (Identifier Code)	Serial payments only. Account with institution is optional and can be provided in option A, B, C or D. Formats B, C are rarely used and most of the time not supported by banks. Option A is formatted [/1!a][/34x] (Party Identifier) 4!a2!a2!c[3!c] (Identifier Code / BIC) Field 57 is used when the receiver of the SWIFT MT103 doesn’t own the beneficiary account and needs to send the Message Further. In the final MT103 on the chain, the holder of the account will be the receiver and no field 57 will be required anymore. We need to parse the BIC out of it or hash the address (priority over header)
		D	Hong Kong Banking Assoc. Avenue du Léman 1204 Genève - CH Switzerland	If no BIC is available to identify the target institution, option D is used. In principle minimum 3 lines with name and address should be provided Format : [/1!a][/34x] (Party Identifier ) 4*35x (Name and Address)
Beneficiary Institution	58	A	BNPAFRPP or e.g. /FR123509321... BNPAFRPP	Format [/1!a][/34x] (Party Identifier) 4!a2!a2!c[3!c] (Identifier Code)	Beneficiary Institution is a mandatory field. In the Case of MT 202 and MT 202.COV, beneficiary institution is the most reliable and straightforward way to identify the eventual beneficiary institution of the founfs.
		D	BANQUE DELUBAC ET CIE 16 PL SALEON TERRAS 07160 LE CHEYLARD	Format [/1!a][/34x] (Party Identifier) 4*35x (Name and Address)
Sender to Receiver Information	72		/INS/BNPAFRPP	This is an optional field. It takes the Format 6*35x. There can be many codes indicating additional information. INS is a code indicating that BNPAFRPP is the instructing institution. Without field 72, the receiver may not know it since that information is not provided somewhere else in the message when sender is the next bank on the routing chain and ordering institution is another bank before the instructing one.

2.3.3 Additional notes on MT202

Some complementary notes:

When no correspondent is used neither on sender side (Tag 53A) nor on receiver side (Tag 54A) and No reimbursement party (Tags 56a and 57a) is indicated in the SWIFT MT103 message. It means
- There’s a direct account relationship, in the currency of the transfer, between the Sender and the Receiver. Money will be taken from account and credited to the beneficiary.
- Beneficiary customer account (:59:/00012367493) is hold by the receiver.
What to do in case of 57D if we cannot find a country code? We Use SWIFT message Receiver BIC country (sometimes wrong but better than nothing, only sometimes since when 57D is used we are likely in the same country
Routing
- When there is no ordering institution (Tag 52) in the SWIFT MT202 message. That means implicitly that the ordering customer is customer of the Sender.
- When the ordering institution (Tag 52D) is provided in the MT202 SWIFT Message. This means the ordering customer is not customer of the Sender.
  - Either the sending institution sends the MT202 on behalf of the ordering institution in 52D. This happens when the ordering institution is a small bank that has an agreement with a major bank (sending bank) for the processing and settlement of currency transactions. The small bank can use the correspondent network of sending institution.
  - Or the Sender is a routing bank on the chain
Field 57 is used when the receiver of the SWIFT MT103 doesn’t own the beneficiary account and needs to send the Message Further.
In the final MT103 on the chain, the holder of the account will be the receiver and no field 57 will be required anymore.
- This indicates that Sender and Beneficiary customer's Bank do not have direct account relationship in the currency of the transaction (USD). Otherwise the sender would send the message directly to the beneficiary customer's Bank.
The field 58a identifies in a unique way the beneficiary institution. To be perfectly honest, it does not have the same meaning as the 57a in 103 for instance, it rather has the same beaning as 59 to identify the beneficiary, when the beneficiary is an institution and not a customer. We shall use the 58 for 202 and 202.cov to identify the eventual beneficiary institution.

2.4 SWIFT MT202 COV Detailed Analysis

MT202 COV is a SWIFT message format for financial institution (FI) funds transfer between financial institutions. MT202's are used primarily for two purposes, bank-to-bank payments (i.e. interest payments and settlement of FX trades) and Cover Payments.
MT202 COV was implemented in 2009 to create traceability of the origination of funds (institution and account) through to the destination of funds (institution and account.) This was in response to anti-money laundering and associated banking requirements.

Prior to MT202 COV, The message format, MT202, did not include origination/destination financial institution information. Particularly for Cover Payments, where a combination of MT103 and MT202 are used to direct funds transfers to a beneficiary account, the intermediate banks in the MT202 had no ability to understand and perform risk analysis/AML/compliance checks on the funds transfer based on the original and destination of the funds. Thus, intermediate banks could be unwittingly involved in illegal transactions under new regulations.

The situation of SWIFT MT202 COV in a banking institution is as follows:

There can be two different situations:

Either the bank is the initial sending institution, in which case it will be identified both as the sender of the SWIFT message and perhaps as the Ordering Institution (52a)
Or the bank is just a routing bank in the routing chain in which case it is the sender but shall be different that the Ordering Institution (52a)

2.4.1 MT202 COV Introductory examples

This section presents various examples of SWIFT MT202 COV corresponding to different situations

2.4.1.1 MT202 COV Example: Cover payment

We’ll now go through a case where the MT202 COV followed as the MT103 sent as an announce as part of the cover payment method as introduced in section [6.2.2.4 Example 4: Announce message (cover method)]. This is the case when the initial sending institution and the eventual beneficiary institution have no relationship together and decide to go through their correspondent.
The MT 202 COV in this case is the message actually carrying the funds.

In this example, the customer John Trump of bank XYZ in Switzerland wants to send 1’000’000 USD to Cowboy Corp. in Kensas City, a customer of “Kensas Credit”
Due to the nature of the transaction and their missing banking relationship together, they decide to go through correspondent banks :

An MT103 is sent directly to the beneficiary bank, regardless of the fact they have no banking relationship together
An MT202.COV will be routed through correspondent(s) and routing banks

We are here first having a look at the initial MT202 COV sent by bank XYZ, the sending institution:

Details of the SWIFT MT 202 COV message:

The field account with institution- 57a - ends up by Wells Fargo. The MT 202 chain doesn’t carry the funds any further.
But the account by Wells Fargo is the correspondent account of Kensas Credit by Well Fargo, the field Beneficiary Institution - 58a - identified the institution owning that account by Wells Fargo, hence Kensas Credit.
The field 59 identifies the beneficiary customer for which the funds are transferred, Cowbow corp, a customer of Kensas Credit.

We shall have a look at all the MT202 COV of the chain to see how they differ from each other’s:

2.4.2 MT202 COV Parsing and Data Mapping

The MT202 COV parsing details are presented in the table below. Only most essential fields are discussed.

Meaning	SWIFT		Example	Comment
	Field	Variant
AppID	Block1/ApplId		F	The Application Identifier identifies the application within which the message is being sent or received. The available options are: F = FIN , A = GPA, etc. These values are automatically assigned by the SWIFT system and the user's CBT.
ServiceID	Block1/Servid		01	The Service Identifier consists of two numeric characters. It identifies the type of data that is being sent or received and, in doing so, the type of the following message
Sender (Sending bank / BIC)	Block1/ LTaddrBlk1 (I) Or Block2/ LTaddrBlk2 (O)		SGOBFRPP	Sender BIC appears in header block (Block 1) in the MT202 Input and in the application block (Block 2) in the MT202 Output (Input and output related to the SWIFT network, not the bank). Need to use field Block2 / Inoutind to find out
Message Type	Block2/ Msgtype		202	SWIFT Message Type = MT 202
Validation Flag	Block3/Tag119		COV (if MT202 is a cover payment)	This validation flag is provided the user block (Block 3) and transported end-to-end. It indicates that the message is a MT202 Cover.
Receiver (Receiving Bank / BIC)	Block2/ LTaddrBlk2(I) Or Block1/ LTaddrBlk1 (O)		RBOSGB2L	The Receiver BIC appears in header block (Block1) in the MT292 Output and in the application block (Block 2) in the MT202 Input. (Input and output related to the SWIFT network, not the bank). Need to use field Block2 / Inoutind to find out. The receiver of the message is the eventual beneficiary only if no field 57 says otherwise.
Unique End-to-end Transaction Reference	Block3/ Tag 121		b03c6901-bbed-4aa9-afdh-A5bc26d19257	This reference is provided in the user block (Block 3) and transported end-to-end. It is mandatory in MT103 but can still be missing as well as have duplicates.
Sequence A - General Information (Matching MT 202 format)
Sender's Reference	20		ORDERREF1234	This field is mandatory and of format 16x. It is a reference assigned by the Sender to unambiguously identify the message.
Related reference	21		123456789ABCDEF	This field is mandatory and of format 16x.
Sender Msg. Sending Timestamp	(O) Block2 / ‘ Intime + Indate (I) Sys.time()		1538070522	(O) = Output only : SWIFT timestamp for an Output message (HHMMYYMMDD) or local date/time for an Input Message.
In / Out-put flag	Block2 / Inoutind		I	Single letter ‘I’ or ‘O’
Value Date / currency / interbank settled amount	32	A	180816USD2325,	It is mandatory and of format 6!n3!a15d (Date)(Currency)(Amount). Note the trailing coma (i.e. decimal part is not mandatory if 0)
Ordering institution	52	A	BNPAFRPP or e.g. /FR1235093212... BNPAFRPP	Format [/1!a][/34x] (Party Identifier) 4!a2!a2!c[3!c] (Identifier Code)	Ordering institution is optional and can be provided in two options A (usual) and D (less common). The sender populate this field to indicate that the initial instruction comes from another institution (ordering institution). The ordering institution remains constant in the message chain. (priority over header)
		D	BANQUE DELUBAC ET CIE 16 PL SALEON TERRAS 07160 LE CHEYLARD	Format [/1!a][/34x] (Party Identifier) 4*35x (Name and Address)
Sender's correspondent	53	A	PNBPUS3N or e.g. /12345678901 PNBPUS3N	Cover payments only Correspondent of sender. Sender has an account in Currency with this banking institution. Option A is formatted [/1!a][/34x] (Party Identifier) 4!a2!a2!c[3!c] (Identifier Code / BIC)
		B	/12345678901	Caution : Serial and cover payments. Field 53B indicates the account number of the Sender, serviced by the Receiver, which is to be used for reimbursement (debit) in the transfer. This the account of the sender by the receiver (VOSTRO) Option B Format is: [/1!a][/34x] (Party Identifier) [35x] (Location) The field is optional but In practice, the account number is almost always provided.
Receiver’s correspondent	54	A	IRVTUS3N or e.g. /9876412-1234/123 IRVTUS3N	Cover payments only. Correspondent of receiver. Receiver has an account in currency with this banking institution. Option A is formatted [/1!a][/34x] (Party Identifier) 4!a2!a2!c[3!c] (Identifier Code / BIC)
Intermediary Institution	56	A	IRVTUS3N (bic) or e.g. /939400 (BSB or account) AMPBAU2SXXX (bic)	Serial payments only. This is the Correspondent of Creditor Bank. It holds the account in currency of the creditor bank. It is used instead of over 54a (Receiver's Correspondent) in case of a serial payment transfer. It is optional and can be provided in option A, C or D. Formats C or D are rarely used and most of the time not supported by banks. Option A is formatted [/1!a][/34x] (Party Identifier) 4!a2!a2!c[3!c] (Identifier Code / BIC)
Account With Institution	57	A	BARCGB22XXX (bic) or e.g. //939400 (BSB) AMPBAU2SXXX (bic)	We need to parse the BIC out of it Format : [/1!a][/34x] (Party Identifier ) 4!a2!a2!c[3!c] (Identifier Code)	Serial payments only. Account with institution is optional and can be provided in option A, B, C or D. Formats B, C are rarely used and most of the time not supported by banks. Option A is formatted [/1!a][/34x] (Party Identifier) 4!a2!a2!c[3!c] (Identifier Code / BIC) Field 57 is used when the receiver of the SWIFT MT103 doesn’t own the beneficiary account and needs to send the Message Further. In the final MT103 on the chain, the holder of the account will be the receiver and no field 57 will be required anymore. We need to parse the BIC out of it or hash the address (priority over header)
		D	Hong Kong Banking Assoc. Avenue du Léman 1204 Genève - CH Switzerland	If no BIC is available to identify the target institution, option D is used. In principle minimum 3 lines with name and address should be provided Format : [/1!a][/34x] (Party Identifier ) 4*35x (Name and Address)
Beneficiary Institution	58	A	BNPAFRPP or e.g. /FR123509321... BNPAFRPP	Format [/1!a][/34x] (Party Identifier) 4!a2!a2!c[3!c] (Identifier Code)	Beneficiary Institution is a mandatory field. In the Case of MT 202 and MT 202.COV, beneficiary institution is the most reliable and straightforward way to identify the eventual beneficiary institution of the founfs.
		D	BANQUE DELUBAC ET CIE 16 PL SALEON TERRAS 07160 LE CHEYLARD	Format [/1!a][/34x] (Party Identifier) 4*35x (Name and Address)
Sender to Receiver Information	72		/INS/BNPAFRPP	This is an optional field. It takes the Format 6*35x. There can be many codes indicating additional information. INS is a code indicating that BNPAFRPP is the instructing institution. Without field 72, the receiver may not know it since that information is not provided somewhere else in the message when sender is the next bank on the routing chain and ordering institution is another bank before the instructing one.
Sequence B - Underlying Customer Credit Transfer Detail
Currency / Instructed Amount	33	B	USD2350,	Normally optional in the standard. It may be provided for instance because the sender has taken fees. See field 71F below. Format 3!a15d (Currency)(Amount)
Ordering Customer	50	A	/DE3750070010... DEUTDEFF	Line 1 (subfield Party Identifier) /34x (account) Line 2 (subfield bank) 4!a2!a2!c[3!c] (Identifier Code)	The field ordering customer is mandatory. In can be given either in the message details (here) or per transaction in the repeating sequence. The ordering customer is customer of the sender only if there is no field 52. The ordering customer remains constant in the message chain.
		F	/DE207008000... 1/Essilor International 2/147 Rue de Paris 3/FR/Charenton-le-Pont, 94220	Line 1 (subfield Party Identifier) /34x (Account) Lines 2-5 : (Number/Name and Address) 1!n/33x (Number)(Details)
		K	/CH5704835098... GALLMAN COMPANY GMBH RAEMISTRASSE, 71 8006 ZURICH SWITZERLAND	Line 1 : (subfield party identified) /34x (Account) Line 2-5 (subfield Address) 4*35x (Name and Address)
Beneficiary	59	(no letter)	/26351-38947 Company One CITY STREET 50 LONDON, UK	Line 1 : [/34x] (Account) (IBAN format or else) Line 2-5: 4*35x (Name and Address)	Beneficiary customer information is Mandatory. The beneficiary remains constant in the message chain.
		A	PNBPUS3N or e.g. /12345678901 PNBPUS3N	Option A is formatted [/1!a][/34x] (Party Identifier) 4!a2!a2!c[3!c] (Identifier Code / BIC)
		F	/10078074 1/Company One 2/CITY STREET 50 3/GB/LONDON	Line 1 (subfield Party Identifier) [/34x] (Account) Lines 2-5 : (Number/Name and Address) 4*(1!n/33x) (name and address)
Remittance Information	70		/INV/18042-090715	Remittance information is optional and provided in format 4*35x if available. Up to 4 lines of up to 35 X characters each. Usually the remittance information is generated by the beneficiary and sent to the ordering customer (or debtor). The beneficiary requests the debtor to provide it the payment message, so that the beneficiary can easily reconcile the payment with an invoice for instance.
Details of Charges	71	A	OUR	It is mandatory and of format 3!a. It can take 3 values: BEN, OUR and SHA. OUR means charges are to be borne by the ordering customer. SHA means charges are shared between Ordering and beneficiary customers. BEN means charges are to be borne by the beneficiary
Sender's charges	71	F	EUR2,50	Optional. When 71A is BEN (or SHA), 71G contains amount of the charges due, which have been deducted from the interbank settlement amount. Interbank settled amount = Instructed amount - Sender's charges. Format 3!a15d Caution: there can be several different 71F in a same MT202 COV.
Receiver's charges	71	G	EUR2,50	Optional. When 71A is OUR (or SHA), 71G contains amount of the charges due, which have been prepaid and included in the interbank settlement amount. Format 3!a15d Caution : there can be several different 71G in a same MT202 COV.
Sender to Receiver Information	72		/INS/BNPAFRPP	This is an optional field. It takes the Format 6*35x. There can be many codes indicating additional information. INS is a code indicating that BNPAFRPP is the instructing institution. Without field 72, the receiver may not know it since that information is not provided somewhere else in the message when sender is the next bank on the routing chain and ordering institution is another bank before the instructing one.

2.4.3 Additional notes on MT202 COV

Some complementary notes:

The option field 53B (only variant B) is really only used to indicate which account at the correspondent (receiver) should be debited.
Fields 51A seems to be not supported by most banks (at least all I found such as UBS, etc.)
When no correspondent is used neither on sender side (Tag 53A) nor on receiver side (Tag 54A) and No reimbursement party (Tags 56a and 57a) is indicated in the SWIFT MT202 message. It means
- there is a direct account relationship, in the currency of the transfer, between the Sender and the Receiver. Money will be taken from account and credited to the beneficiary.
- Beneficiary customer account is hold by the receiver.
What to do in case of 57D if we cannot find a country code? We Use SWIFT message Receiver BIC country (sometimes wrong but better than nothing, only sometimes since when 57D is used we are likely in the same country
Routing
- When there is no ordering institution (Tag 52) in the SWIFT MT202 message. That means implicitly that the ordering customer is customer of the Sender.
- When the ordering institution (Tag 52D) is provided in the MT202 SWIFT Message. This means the ordering customer is not customer of the Sender.
  - Either the sending institution sends the MT103 on behalf of the ordering institution in 52D. This happens when the ordering institution is a small bank that has an agreement with a major bank (sending bank) for the processing and settlement of currency transactions. The small bank can use the correspondent network of sending institution.
  - Or the Sender is a routing bank on the chain
Field 57 is used when the receiver of the SWIFT MT202 doesn’t own the beneficiary account and needs to send the Message Further.
In the final MT103 on the chain, the holder of the account will be the receiver and no field 57 will be required anymore.
- This indicates that Sender and Beneficiary customer's Bank do not have direct account relationship in the currency of the transaction (USD). Otherwise the sender would send the message directly to the beneficiary customer's Bank.
Sender’s reference is new for every message in the routing chain, but end-to-end reference remains constant.
The field 58a identifies in a unique way the beneficiary institution. To be perfectly honest, it does not have the same meaning as the 57a in 103 for instance, it rather has the same meaning as 59 to identify the beneficiary, when the beneficiary is an institution and not a customer.
We shall use the 58 for 202 and 202.cov to identify the eventual beneficiary institution.

3. Conclusion

The above is a collection of the most essential information we gathered at NetGuardians when implementing SWIFT parsing to monitor payments, specifically cross border payments. There are more Message Types relevant when it comes to monitoring payments than those mentioned in this article (for instance MT 205, MT 102, MT 203, etc.) but there usage is rarer.
In addition, the listing of fields provided in this article is far from complete and other fields of the SWIFT messages, especially from the various headers, may be interesting for your own business. I let the reader refer to the SWIFT MT specifications.
Last but not least, with the coming mandatory transition to XML format (SWIFT MX), I may well need to write a new version of this article pretty soon :-)

For the sake of exhaustivity, I wanted to complete this article by giving a very simplified view of how SWIFT kicks-in in a Banking Information System:

Most importantly, the SWIFT interface is connected to the payment HUB of the banking institution. But interestingly, it is also used as an input channel for customers, since the later may send Transfer Requests such as MT101 to their banking institution using SWIFT.

Interview about NetGuardians and fighting fraud in the digital era

2019-02-04T06:10:18-05:00

The below is an extract from an interview I ran in February 2019 during the EPFL Forward event.

NetGuardians is a Swiss Software Publisher based in Yverdon-les-bains that edits a Big Data Analytics Solution deployed Financial Institution for one key use case: fighting financial crime and preventing banking Fraud.
Banking fraud is meant in the broad sense here: both internally and externally.
Internal fraud is when employees misappropriate funds under management and external fraud is when cyber-criminals compromise ebanking applications, mobile devices used for payment or credit cards.

In the digital age, the means of fraudsters and cyber-criminals have drastically increased.

Cyber-criminals have become industrialized, professionalized and organized. The same technology they use against banks is also what gives us the means to protect banks

At NetGuardians we deploy an Artificial Intelligence that monitors on a large scale, in depth and in real time all activities of users, employees of the bank, but also those of its customers, to detect anomalies.
We prevent bank fraud and fight financial crime by detecting and blocking all suspicious activity in real time.

Jérôme Kehrli, how did you manage to convince a sector that is, in essence, very traditional, to trust you with your digital tools to fight against fraud?
Two different worlds, two languages, two visions?

The situation of the banks is a bit peculiar, the digitization and with it the evolution of the means and the behaviours of the customers in the digital age, was at the same time both a traumatic and a formidable solution.

The digital revolution was a traumatic because the banks, which by their very nature are very conservative, especially in Switzerland with our very strong private banking culture, were not prepared for the need to profoundly transform the customer experience of the banking world: to meet the customer where he is, on his channels, with mobile banking, this culture of all and everything immediately, with instant payments, the opening of the information system, with the explosion of the External Asset Managers model and external service providers with the PSD2 European standard, etc.

The digital revolution has imposed these changes, sometimes brutally, in banks and it is the source of a tremendous increase of the attack surface of banks.

But this same technology that spawned the digital revolution has proved to be the solution too.
Technology has made it possible to build digital banking applications that provide all of the bank's services on a mobile device.
Technology has made it possible to implement innovative solutions that secure the information system and protect client funds.

And in this perspective, Artificial Intelligence is really a sort of panacea: robot advisory, chatbots, personalization of financial advice and especially, especially the fight against financial crime: banking fraud and money laundering

In the end, if five years ago our solutions seemed somewhat avant-garde, not to say futuristic and sometimes aroused a bit of skepticism, today the banks are aware of the digital urgency and it is the bankers themselves who eagerly seek our solutions.

You support the digital shift of the banking sector.
Do banks sometimes have to change their way of operating, their habits, to be able to use your technologies?
(Do you have to prepare them to work with you?)

So of course the digital revolution profoundly transforms not only the business model but also the corporate culture, its tools, and so on.

At NetGuardians we have a very concrete example.

Before the use of Artificial Intelligence, banks protected themselves with rules engines. Hundreds of rules were deployed on the information system to enforce security policies or detect the most obvious violations.
The advantage with rules was that a violation was very easy to understand. A violation of a compliance rule reported in a clear and accurate audit report was easy to understand and so was the response.
The disadvantage, however, was that the rules were a poor protection against financial crime and that's why fraud has exploded over the decade.

Today with artificial intelligence, the level of protection is excellent and without comparison with the era of the rules.
But the disadvantage of artificial intelligence is that accurately understanding a decision of the machine is much more difficult.

At NetGuardians, we develop with our algorithms a Forensic analysis application that allows bankers to understand the operation of the machine by presenting the context of the decision.
This forensic analysis application, which presents the results of our algorithms, is essential and almost as important as our algorithms themselves.

This is a powerful application but requires a grip.

Tom Cruise in Minority Report who handles a data discovery application playing an orchestra conductor, it's easy in Hollywood, but it's not in reality.
In reality, we provide initial training to our users and then regular updates.

In the end, a data analysis and forensic application is not Microsoft Word. Our success is to make such an application accessible to everyone, but not without a little help.
In conclusion i would say that the culture transformation end the evolution of the tools do require some training and special care.

In general, what should a company prepare for, before making a digital shift?

In the digital age, many companies must transform their business model or disappear. Some services become obsolete, some new necessities appear.
We can mention Uber of course but also NetFlix, Booking, eBookers, etc.

For the majority of the industrial base, the digitalization of products and services is an absolute necessity, a question of survival.

Successful process and business model transformation often requires a transformation of the very culture of the company, down toits identity:
Among other things one could mention the following requirements:

scaling agility from product development to the whole company level
involving digital natives to identify and design digital services
realizing the urgency or if necessary create a sense of urgency
understanding the scale of the challenge and the necessary transformation. Some say "if it does not hurt, it is not digital transformation"

In summary I would say that a company is "mature" for digitalization if it is inspired by the digitalization of our daily life to adapt its products and services AND if it has the ability to execute its ideas.
Ideas without the ability to execute leads to mess, the ability to execute without the ideas leads to the status quo.

From there I would say that a company must prepare itself on these two dimensions, bring itself the conditions and resources required to identify and to design its digital products and those required to realize them.

Artificial intelligence for banking fraud prevention in the digital era

2018-07-04T15:34:04-04:00

The digitalization with its changes of means and behaviours and the induced society and industrial evolution is putting increasingly more pressure on banks.
Just as if regulatory pressure and financial crisis weren't enough, banking institutions have realized that they need to transform the way they run their business to attract new customers and retain their existing ones.
I detailed already this very topic in a former article on this blog: The Digitalization - Challenge and opportunities for financial institutions.

In this regards, Artificial Intelligence provides tremendous opportunities and very interesting initiatives start to emerge in the big banking institutions.

In this article I intend to present these three ways along with a few examples and detail what we do at NetGuardians in this regards.

Digital urgency

Since 10 years, since the first Iphone, the banking business is under intensive transformation, like the whole society. The iphone, then all the next generations of smartphones, has allowed the always and everywhere interconnection of everyone, 4 billion people today, more tomorrow. But even more than this interconnection, the real revolution was the user experience offered by these new devices, providing access to vital services at one finger touch away.
The current generations, millennials, and the rising Z generation, these young people born with a smartphone, do not share the values than their ancestors. These new generations are characterized by their need of absolute, of immediacy, everything and immediately, of individualization, all about me, myself and I, and of universal service, where I want, when I want and especially how I want.

As a result, banks, if they want to retain their customers, or seduce these young active people who are coming on the market, must adapt, transform, and digitalize their businesses. This topic is far from new, and the amazing slap given to the banks by the emergence of the fintechs and their cannibalization of the banking business was way enough to create the sense of urgency required to trigger the transformation of banks.

Today all banks are adapting, developing more personalized and massively online services, meeting the new active force on its privileged channels, mobile first, but also social networks, youtube, etc
One might want to read my previous article on this very topic: The Digitalization - Challenge and opportunities for financial institutions

In this race for digital, made vital by the crumbling margins, new technologies are both the source of the challenges and their solution. In this perspective, Artificial Intelligence and advanced algorithms are the next step, the way to scale and have the potential to make banks more innovative and smarter. To meet the challenges of digital and the demands of this population with new behaviors and uses, but also to take advantage of opportunities related to digitalization, AI proves to be a panacea.

At every level, from financial research to fraud prevention, AI can do better, faster, farther, stronger.
Today an lot of highly innovative initiatives, taking advantage of the latest advances in artificial intelligence, emerge in the big banks, the most able to consent to the investments needed for the transformation.

These initiatives are mainly around 3 axes:

1. The customer experience

The physical presence vanishes, the contact with a human also and is replaced advantageously, at least for these digital generations, by a computer system: chatbot, personal banking assistant, voice assistant, etc.

Bank of America, for instance, has deployed a virtual assistant, Erica, that interacts with her customers by voice chat or chat and is responsible for answering customers' questions, but who is also able to provide financial advices, recommendations of investment, or to carry out the simplest banking operations such as payments, fund transfers, etc. These new banking channels are available constantly, everywhere and in various forms, "When I want, where I want and especially as I want."

2. Advanced analytics, operational efficiency and service customization

New technologies and machine learning techniques are able to substitute to humans on many analytical tasks in an advantageous way, be it financial research, investment optimization or customer profiling for the personalization of advisory.

UBS, for instance, has developed virtual research agents able to performing investment research tasks, from analyzing market data to company valuation at a level comparable to human analysts but much faster.
RBS has implemented a robot for the loan evaluation process able to approve a credit in 45 minutes, instead of several days as previously required.

3. Prevention of bank ingfraud and anti-money-laundering

The new channels to which banks must subscribe, the new usages of customers and the acceleration of business cause an increase of the attack surface of banks. These uses especially, and the behaviors of these digital generations, share everything with everyone, all about myself, my life online, social networks where everything is shared, facilitate all forms of attacks, from social engineering to theft of eBanking session.

Finally, the new technologies, on one side, since they offer new means to cyber-criminals, and the economic context on the other side, which makes the criminal enterprise attractive to a number of engineers and other qualified computer scientists, cause an explosion of fraud cases, increasingly external.

AI against banking fraud, a bit of history

In the early 2000s, the detection of banking fraud relies mostly on internal control and auditing. The effectiveness of these approaches is pretty low because of their inherent limitations. Working by sampling, internal control and audit leave a lot of frauds pass through the cracks. Some additional securities are implemented within the bank's operational information system, but here too their efficiency is quite relative.
At that time, the subprime crisis and the southern european countries sovereign debt crisis have not yet occurred, the margins are wide, people trust the banks and overall, they feel safe. The fight against fraud is not perceived as a priority.

In the second half of the 2000s, the maturity of cyber-criminals, their organization and the complexity of their attacks explode, multiplying the losses associated with fraud.
Banks react by massively deploying specific analytical systems aimed at detecting fraud. At that time, these systems are rule engines seeking behavioral patterns or pre-established and well-determined conditions or patterns in audit trails of the information system.

Today, the complexity of attacks and the means of cyber-criminals are such that these rule engines are defeated. We can mention the computer crash of the central bank of Bangladesh, where cyber-criminals, safe and untraceable, managed to steal $81 million or the Retefe worm, which despite the means deployed still manages to divert about fifty ebanking sessions every day, today, in Switzerland.
The rule engines are outdated for various reasons, including changes in usage, their multiplication and the complexity of bank customer behavior. How can the same set of rules effectively protect customers with different uses and behaviors, for example a simple saver on one side and an institutional account used to pay the suppliers of a company on another side?

Today, banks no longer have any choice and deploy large-scale AI techniques to protect their Assets Under Management and their customers.

Return of Experience, our approach at NetGuardians

In the first half of the current decade, we started at NetGuardians to develop our first AI approaches, leveraging the analytics capabilities of our Big Data platform. These approaches consist in analyzing in real time all the bank transactions, with a depth of analysis of several years, to let the machine learn the transactional behavior of both the bank's customers (external fraud) and its employees (internal fraud). With this in-depth understanding of the habits, behaviors and practices of these two populations, the machine can qualify each and every transaction as legitimate or potentially fraudulent, and, if necessary, block it before the funds have left the bank.

We then introduced other machine learning algorithms to dynamically build customers peer-groups with similar behavior, allowing us to compare an individual transaction not only with the profile of a specific customer but also with its peer group, and reducing thus the irrelevant alerts, these false-positives which must nonetheless be analyzed. Later, we focused on broadening the vision of AI by trying to make it understand all patterns of interaction between humans, employees or customers, and the information system of the bank, by analyzing not only transactions but also all other types of interaction.

Today we are able to effectively block each suspicious transaction or activity, while drastically reducing the number of cases to be analyzed, these infamous false positives, and also the time required for the investigation of a case by the teams of the bank.

All of this is explained in details in yet another article on this blog: Artificial Intelligence for Banking Fraud Prevention

Customer experience, the machine in contact with customers

The next step consists in putting the IA directly in touch with the bank's customers. When a suspicious transaction is detected, instead of mandating a bank anti-fraud employee to analyze the situation, which investigation usually ends up with a call to the customer for re-confirmation, the future is to let the machine contact the customer itself, by means of an application installed on the mobile of the customer, or by means of a voice chatbot able to contact him and speak to him to obtain directly the confirmation required for the validation of the transaction.

The benefits are numerous. For the customers of the banks it is a question of bringing this "callback" as close as possible to the input of the transaction, from a few hours today to a few seconds in the future. For the banks it is a question of reducing the costs of intervention while eliminating the frauds by systematically delegating the re-confirmation of the suspicious transactions to the customer.

In the end, the bank protects its reputation, its Asset Under Management, the data of its customers, but also meets them - meet the challenges of the digital - while reducing its operational costs - benefit from its opportunities.

Artificial Intelligence for Banking Fraud Prevention

2018-04-30T08:57:44-04:00

In this article, I intend to present my company's - NetGuardians - approach when it comes to deploying Artificial Intelligence techniques towards better fraud detection and prevention.
This article is inspired from various presentations I gave on the topic in various occasions that synthesize our experience in regards to how these technologies were initially triggering a lot of skepticism and condescension and how it turns our that they are now really mandatory to efficiently prevent fraud in financial institutions, due to the rise of fraud costs, the maturity of cybercriminals and the complexity of attacks.

Here financial fraud is considered at the broad scale, both internal fraud, when employees divert funds from their employer and external fraud in all its forms, from sophisticated network penetration schemes to credit card theft.
I don't have the pretension to present an absolute or global overview. Instead, I would want to present things from the perspective of NetGuardians, from our own experience in regards to the problems encountered by our customers and the how Artificial Intelligence helped us solve these problems.

This article is available as a slideshare presentation here https://www.slideshare.net/JrmeKehrli/artificial-intelligence-for-banking-fraud-prevention-95475760

A video of the speech is available on youtube:

1. Early times, the 2000s

Before 2000, banking institutions are only poorly equipped when it comes to fight financial fraud.

For most of it, detecting fraud cases relies on manual verification and tests performed by

Internal Control
Internal Audit or
External Audits

And unfortunately, this implies a lot of issues:

By working with samples only, Internal control and Audit let a lot of fraud cases pass through the cracks and are found only very late or even never.
Analysis are cumbersome and most often finding fraud cases is not the first and foremost objective of the auditors.

Now of course, the most essential security rules and checks are implemented within the Operational Information System or in the form of procedures to be respected and audited.
Also, some banking institutions already have an Analytics System - or Business Intelligence - at the time and some ad'hoc reports are implemented on top of it that target fraud detection.

In these early times, neither the subprime crisis nor the south European countries debt crisis happened. Margins are important, people trust banks and all in all bankers are happy people.
Fraud cases, mostly internal, exist of course but financial institutions feel rather safe,

2. The late 2000s - fraud costs rise

In the second half of the 2000's, however, the costs linked to fraud, increasingly external, the complexity of attacks and the maturity of attackers rise.
Banking institutions react by deploying quite massively and for the first time specific analytics systems aimed at detecting banking fraud, both external and internal.

At this time, these systems are rules-engines that work by checking or searching pre-defined and well defined conditions within the data extracted from the information system.

In a way these systems can be considered as simple extensions of the security checks and rules implemented directly within the operational information system. These solutions come most of the time from the AML - Anti Money Laundering - World, their editors having understood that banking fraud was a an interesting opportunity to extend their sales.

A very simple rule example would be as follows:

At this time, a first set of papers have already been published on the success, still somewhat relative in this early days, of some Machine Learning approaches implemented towards banking fraud detection.
But Machine Learning and Artificial Intelligence are considered with a lot of condescension and skepticism.
Bankers and their engineers are not willing to consider an approach whose interpretation of results is deemed fuzzy.

NetGuardians has been founded at these times and the NetGuardians platform could be seen then as a gigantic rule engine.

3. The reality of fraud changes dramatically

Unfortunately, the reality of fraud and financial cybercrime evolved fast and dramatically.

Let me give you two examples

3.1 The Bangladesh Bank heist

(Source : https://www.bankinfosecurity.com/bangladeshi-bank-hackers-steal-100m-a-8958)

In February 2016, a group that we deem around 20 persons, composed by financial experts, software engineers and hackers have attacked the information system of the Bangladesh Central Bank.
They manage to compromise the bank internal gateway to the SWIFT Network. The SWIFT network is the international banking messaging network used by banks to communicate and transfer money through electronic wire. The pirates used the SWIFT network to withdraw money from the Bangladesh Central bank VOSTRO account by the US Federal Reserve.
They manage to transfer 81 millions USD to the Philippines and used the Philippino casinos to launder the stolen funds.

As a sidenote, the fact that they have stolen "only" 81 million USD is an amazing luck for the bank, or rather an amazing bad luck for the cybercriminals.
An Anti-Money laundering system - rule-based - deployed in the US federal Reserve for Anti-Money Laundering blocked the 6th transaction because the beneficiary name contained the word "Jupiter". Jupiter was on a sanction screening list in the US because a cargo ship navigating under Iranian flag was named "Jupiter" something. The 6th transaction being blocked, all the further ones, a little less than thirty, have been blocked as well.
But 5 transactions pass through before the 6th has been blocked by the Fed and went further through the correspondent banking network.
Another transaction has been blocked by the Deutsche Bank, a routing bank, because of a typo: "Shilka Fandation" instead of "Shilka Fundation".
So only 4 transactions our of 35 successfully arrived to the Philippines and as such the total loss have been reduced from 951 million USD initially intended to "only" 81 millions USD.

As a fun note, a few week after the heist, all the responsibles of the financial institutions involved, the US Fed Reserve, the Bangladesh Central Bank, even the finance minister of the Philippines were all convinced that the money - or at least a significant part of it - would be recovered and that the cybercriminals would be caught.

Two years after, today, we know that we will never recover these funds.
The attacker are safe, untraceable and will never be found. We believe that this is a group of about 20 persons who worked on the heist preparation for about 18 months. 81 million USD is a pretty number.

Now you think ... But this is Bengladesh ... right ?
Here we are in Europe ... Even better, here we are in Switzerland ... right ? And in Switzerland we don't really feel concerned by the numerous security holes in the Bangladesh Central Bank Information System. So let me give you another example...

3.2 The retefe Worm

Quoting https://www.govcert.admin.ch/blog/33/the-retefe-saga:

"This threat actor has already been around for more than four years...
Their goal remains the same: committing e-banking fraud in Switzerland and Austria.

In August 2017, Retefe still redirects between 10 and 90 e-banking sessions every day."

The Retefe worm is a worm developed by a team of cybercriminals targeting specifically the ebanking platforms of small and mid size Austrian And Swiss Banking Institutions.
The worm is used by the thieves to take control of the victim's ebanking sessions and to submit fraudulent transactions to the system.

This worm is 4 years old.
For 4 years, fraudsters keep on updating it, modifying it and extending it to counter the anti-viruses software and the specific protections put in place by the banks.
This worm is 4 years old and nevertheless, as pointed out by the Computer Security Section of the Federal Finance Separtment, it is still making today between 10 and 90 victims in Switzerland and Austria.

Today, in the swiss banks ...

My conclusion from these examples is as follows:
Today, fraudsters and cybercriminals are professionals. The time when fraud was mostly coming from little hackers working in their garage or back-office employees disappointed by their bonus, is over. Today, attackers are professionals who have industrialized their methods.

4. Facts and Projections

Some facts and projections to understand what reality banking institutions are facing nowadays...

In frebruary 2016, a group of cybercriminals managed to steal 81 million USD from the VOSTRO account of the Bangladesh Central Bank by the US federal Reserve
This is one of the biggest bank heist in history and the most impressive cybercrime ever

In a report called "Report to the nations", the international association of Fraud Examiners estimated that in 2017, the total cost of fraud has been 3000 billions USD.
In banking fraud, a big part of this amount is related to internal fraud, when bank employees divert funds from their employer.
In Switzerland, of course, thanks to the maturity of the banking business as well as the security checks and practices put in place in banking institutions, internal fraud is marginal, compared to external fraud. But external fraud is a cruel reality, think of the Retefe Worm.

Finally, Cyber Security ventures estimates that by 2021 the total cost of cybercrime will reach 6000 billion USD.

The reality to which banks are confronted nowadays is this one.

5. Historical systems are beaten

The principal implication of this reality, the problem which banking institutions are confronted to nowadays is that historical systems deployed to counter fraud - rules engines - are beaten.

Let's assume that a banking institution wants to define a set of rules aimed at detecting when an attacker diverts a customer account to issue fraudulent transactions.

Imagine the situation of a first customer, someone such as myself, using his ebanking account to pay his loan at the end of the month, his mortgage, his taxes, telephone bills, etc.
In my case, a big transaction withdrawing 20 k CHF from my account for a beneficiary located in Nigeria should raise an alert. It's clearly an anomaly, being completely outside of my usual habits and behaviour.
Imagine now the situation of a another customer, a responsible of acquisitions for a big corporation, a frequent traveler, spending most of his time abroad and using the corporate account to pay big amounts to providers all over the world.
In the case of this second customer, it is on the contrary a small payment benefiting to a counterparty in Switzerland that would be the anomaly and should raise an alert.

If one wants to detect anomalies for these two different situations, one would end up implementing a completely different set of rules for the two distinct customers.
And this is impossible.

Every bank customer, and even user up to a certain level, is different.
Representing everyone's own and private situations with rules would require to implement and manage hundreds of thousands of rules on the system, which, obviously, is impossible.
Only the most common set of rules can be implemented, which means that:

A lot of frauds pass through the cracks.
In addition, in order to catch the biggest frauds, the limits enforced by the rules have to be very low, which has the consequence of flagging a lot of cases to be analyzed - the so called false-positives - requiring an army of analysts to be reviewed and discarded.

The direct consequences for our customers are as follows:

Financial impacts: frauds must be reimbursed. And in addition these analysts spending their days discarding false positives must be paid.
Reputation impacts: a fraud case being communicated in the newspapers is a nightmare for banking institutions. Even without a large scale communication, customers impacted by fraud will loose faith in their bank.
Then I do not need to explain the consequences that the thousands of papers published on the Bangladesh Bank heist had on the Bangladesh central bank.

Rule-based systems are beaten today.
Something else is required to protect efficiently Banking institutions from banking fraud.

6. Artificial Intelligence comes in help

Artificial Intelligence provides the solution to this problem.

In 2016, we started at NetGuardians to integrate the first advanced algorithms, so called Machine Learning algorithms, in our systems.

We let an Artificial Intelligence analyze continuously the history of billions of transactions in the system and learn about individuals habits and behaviours.
With big data technologies, AI can analyze a very extended depth of history and build dynamic profiles for each and every individual capturing his transactional behaviour.
Individuals can be both Customer and Users (Internal Employees):

Profiling customers is required for both Internal and External Fraud.
Profiling users is required for Internal Fraud.

Big Data technologies are key to maintain these profiles up-to-date in real time by tracking each and every interaction between the user and the bank systems.
In addition to a financial transaction direct characteristics such as the beneficiary, the target bank country, the amount of the transaction, its currency, etc., the machine can correlate a lot of indirect characteristics, such as where in the world was located the ATM where the user withdrawn money from, where was he connected to his ebanking session, etc.

For each and every individual a dynamic and up to date profile captures his behaviour and his habits.
Then, each and every financial transaction, regardless of its type, it being a security trade order, an ATM withdrawal or an ebanking payment, is compared against the user profile and a risk score is computed.
Based on this risk score, the machine eventually decides whether the transaction is genuine or not and whether it requires further investigation by a human analyst within the bank.

The gains for our customers of this new approach, based on customer profiling done by AI, is striking.
It has been a game changing shift of paradigm.

In the banking institutions where we can deploy this new generation approach, we almost eliminate the amount of fraud cases passing through the cracks.
And that, by still reducing to 1/3 of what it was before the number of cases flagged by the system to be reviewed by an analyst or fraud investigator (most of them being the so-called false positives).
Not only the amount of cases, but the amount of time required to investigate a case could be reduced by 80% by having the machine presenting the profile of the customer and how the individual transaction deviates from it with relevant and meaningful visualization techniques.
Finally, the number of re-confirmation asked to customers could be reduce to 1/4.

Reducing the time required to investigate a case in addition to the amount of cases to be investigated has a direct financial impact: analysts spend less time investigating such cases and can focus on task with more added value. Drastically reducing fraud cases passing through also has obvious financial impacts.
Now all of this, especially reducing the number of times a re-confirmation is asked to customers has positive impacts on reputation

Now working on a per-customer basis is sometimes still sub-optimal. Sometimes a genuine transaction is always very unusual on a per-customer basis and it is required to broaden the view of the Artificial Intelligence.
Let me give you an example.
Let's imagine that tomorrow I buy a new Audi. That would be a transaction of 60 kCHF leaving my account for a beneficiary - Amag Audi Switzerland - that I never used before. Such a transaction, new beneficiary and huge amount is completely outside of my profile.
Based on this, the AI will decide to block the transaction, requiring a further validation from my end which will annoy me.
So how can we avoid that ?
If we look more carefully and globally at the transactions of this kind, big amounts benefiting to Amag Audi Swritzerland, among the customers with same profiles as myself, are quite usual.

The machine needs a broader view to understand that this transaction is not unusual.

7. The Machine can do better

The machine can look at the big picture and analyze transactions at a broader scale.
Recall the Audi example. When such a transaction is very unusual for a specific customer, looking at other customers with similar conditions, habits and behaviour is required.

And here again AI comes in help.

AI can analyze behaviours and habits of customers and group together the people with same patterns. People that are the same age, same wealth level, same origins, live in the same region, etc. will have a strong tendency to behave the same: for instance drive the same kind of car, such as an Audi, live in a appartments of the same size, pay the same amount of telephone bills at the end of the month, etc.
The machine can analyze customer activities and transactions on a very large scale and cluster together customers with same behaviour.
Then, these groups can be profiled just as individuals.
And finally, a transaction can be scored against the customer group profile in addition to the customer profile.

Recalling the Audi example. When scoring this specific payment against the individual profile, the transaction will be flagged as suspicious.
Scoring it against the group profile will clearly indicate that it's a genuine transaction. People buy new cars every day, especially in Switzerland

With this new approach, looking at the broader scale and comparing customers with each others instead of only scoring transactions in the individual context of a customer, we could improve our fraud detection system further.

The number of cases to be analyzed (false positives) could be reduced further.
In addition, the groups and their profiles happen to be an invaluable source of information for other use cases and concerns within the bank such as marketing, trend analysis, etc.
Of course reducing the number of cases to be handled by the investigation team has a direct impact on operational efficiency and induces further financial gains

Now all of this, transaction scoring and customer clustering works amazingly, but it works after the facts. The transaction has been input in the system and if we are not fast enough, depending on how we integrate within the bank information system, we can be too late, doing only fraud detection and not fraud prevention.
Our idea from here was:

What if we could analyze the User or customer activities even before the transaction is input one the system and detect fraud before it happens ?
What if we could interpret weak signals coming from the analysis of how the Customer interacts with the banking information system to qualify him as legitimate or potentially fraudulent ?

All of this require completely different analysis techniques.

8. Even further

Let me give you a simple example of what I mean by analyzing a customer's interaction with the banking Information system.
The interactions of a customer with the ebanking application is the simplest example I can come up with.

Imagine the situation of a genuine user of the ebanking platform whose behaviour when inputting is payments is always the same:

He logs in the ebanking platform.
He looks at his account balance.
He performed all his payment, from input to validation, many of them.
He checks his pending orders, making sure he missed none of them.
He logs out the platform.

Now if a worm hijacks the ebanking session, the worm will do none of that:

The worm will likely go directly from login to payment input, validation, then logout.

Here I am only showing transitions but one can also consider User think time, keyboard stroke speed, etc.

AI can analyze all this behaviour and activity trails a user or customer leaves on the banking information system and build a probabilistic model capturing this behaviour as a succession of interactions.
Then, when an individual action is performed, the machine can compute the likelihood of that action to be performed by a legitimate user or an attacker based on the path-to-action.
And here as well, AI can build profiles of these activities and their likelihood both at individual level and group level through clustering techniques.

With this kind of analysis, by looking at all the interactions of the users or customers with the banking information systems, AI can look at all individual events and qualify these interactions as legitimate or suspicious regardless of the financial transactions being input or not on the system.

AI can detect a fraud, or the intention to commit a fraud, even before a transaction is input on the system, by analyzing the user or customer activity, in the form of its interactions with the Banking Information System, before inputing the transaction.
In addition, by analyzing the behaviour of the customer as a whole, AI can qualify his interaction session (ebanking, mobile banking, PSD2, etc.) as legitimate or suspicious and kill the session in case of a doubt, thus protecting the information he sees and protecting his privacy in addition to his assets.
Finally, all this understanding of the user or customer habits and behaviour can be used to design even more advanced transaction scoring models.

This ability to detect fraud cases before they happen lead to further improvement of the operational efficiency and operational security of the banking institution.
Protecting the customers privacy in addition to their assets is important to protect the reputation of a financial institution. This is especially important for private banking institutions.

With «AI vs AI», I wanted to illustrate the current research topics we are working on today at NetGuardians to improve our algorithms further.
In a few words, we see today that cybercriminals are increasingly using advanced algorithms on their end to study the banks attack surface and discover means to attack the banks and their customers.
We are in a "cat and mouse" game where attackers attempt to counter the security systems put in place by banking institutions, which in their turn deploy new forms of algorithms and intelligence to protect them further.
I can only be looking forward to telling you more on this matter in a near future...

9. Conclusion

Our own experience and conclusion with AI technologies and it's concrete application on our use cases is striking.

Introducing advanced algorithms, machine learning and advanced analytics techniques in our use cases has been key to help us improve the way we secure financial institutions and their customers.
We could:

Reduce the fraud cases passing through and almost eliminate them.
Reduce the number of cases to be analyzed and make the detection system a lot more relevant.
Drastically reduce the amount of time required to investigate a case.

Today, at our customers, Artificial Intelligence monitors every single interaction between individuals, both customers or employees, and the information system, to qualify their actions as legitimate or fraudulent, in addition to analyzing with highly sophisticated models financial transactions input in the system.
Today our reality is as follows: Artificial intelligence monitors human behavior on a large scale to secure banks and their customers.

But Science Fiction advances much faster than reality. Regarding artificial intelligence, the collective imagination, fed by Musk and Hollywood, is way ahead of reality.
In the public collective imagination, artificial intelligence today generates quite a lot of fantasies.

So let's agree on something if you do not mind.
If one calls weak artificial intelligence, a computer solution able to solve a problem in a strict context, to optimize a solution or a mathematical function, or to look for an answer to a question in a strict context, one calls a strong artificial intelligence an intelligence able to argue, contextualize or to show sensitivity or initiative.
If progress in weak artificial intelligence is today very fast and very impressive, we do not have the slightest little trace of a proof that would allow us to believe one day in the emergence of a strong artificial intelligence. Strong artificial intelligence is science fiction.

The problem is that approach names like Neural Network are generating a lot of fantasy in the public imagination who takes this name literally.
With neural networks, the public imagines a digital brain, whereas the reality is that of "matrices of convolutions", intensive iterative calculations carried out on gigantic numerical matrices. On the other hand, powerful technologies with less evocative names, genetic algorithms, random forests or boosted gradient raise less fantasies.

10. Artificial Intelligence vs. Augmented Intelligence

Today, these Artificial Intelligence techniques give the most impressive results when they support the human and not when they supplant it.

Chess is one of the first areas in which computers started to beat humans.
The examples of algorithms that manage to defeat the great masters of chess in a regular if not systematic are legion.
But these are the so-called "centaurs", most of the time amateur players, but helped by Artificial Intelligence, half-human, half-machines, who now win all the "freestyle" games.

I would like to mention a second example with an experience that has been performed last year.
Melanoma specialists have been asked to identify cancerous lesions based on photos of skin lesions.
These experts had a precision, a success rate of the order of 95%.
An AI based on a Neural Network deployed towards the same objective reached a pretty impressive 93% accuracy, yet failing to beat the experts.
But a set of interns, really rather students that actual doctors, accompanied and helped by an artificial intelligence have reached 97% accuracy, beating both Artificial Intelligence alone and experts

Today, the most impressive results of these technologies come from what is called Augmented Intelligence, when Artificial Intelligence intervenes in support of the human decision process and not to replace it.
And Augmented intelligence is exactly what we do at NetGuardians by providing bankers with the means to prevent fraud cases much more effectively.

11. AI Pillars at NetGuardians

The key pillars which enable us to deploy Artificial Intelligence technologies are as folows:

All of this is pretty straightforward to understand.
I would just insist on two key notions:

The ability to run these analyzes in real time. Be able to analyze the activity of bank customers and users in real time is at the root of the difference between preventing fraud and detecting fraud. It must be possible to work with very low processing times to characterize a transaction before it is placed on the market.
The user experience. The deployed algorithms can be as intelligent as one can imagine, if one is not able to provide investigators and analysts with clear, concise and precise information, allowing them to understand the context of the transaction and the reasons for the system to block it, all this does not work. Users reject the solution. Providing analysts with extremely intuitive and visual means to understand machine decisions is essential.

(This article is available as a slideshare presentation here https://www.slideshare.net/JrmeKehrli/artificial-intelligence-for-banking-fraud-prevention-95475760)

Deciphering the Bangladesh bank heist

2017-11-15T17:03:49-05:00

The Bangladesh bank heist - or SWIFT attack - is one of the biggest bank robberies ever, and the most impressive cyber-crime in history.

This is the story of a group of less than 20 cyber-criminals, composed by high profile hackers, engineers, financial experts and banking experts who gathered together to hack the worldwide financial system, by attacking an account of the central bank of Bangladesh, a lower middle income nation and one of the world's most densely populated countries, and steal around 81 million US dollars, successfully, after attempting to steal almost a billion US dollars.

In early February 2016, authorities of Bangladesh Bank were informed that about 81 million USD was illegally taken out of its account with the Federal Reserve Bank of New York using an inter-bank messaging system known as SWIFT. The money was moved via SWIFT transfer requests, ending up in bank accounts in the Philippines and laundered in the Philippines' casinos during the chinese New-Year holidays.

Fortunately, the major part of the billion US dollars they intended to steal could be saved, but 81 million US dollars were successfully stolen and are gone for good.

The thieves have stolen this money without any gun, without breaking physically in the bank, without any form of physical violence. (There are victims though, there are always victims in such case, but they haven't suffered any form of physical violence)
These 81 million US dollars disappeared and haven't been recovered yet. The thieves are unknown, untroubled and safe.

The Bangladesh bank heist consisted in hacking the Bangladesh central bank information system to issue fraudulent SWIFT orders to withdraw money from the banking institution. SWIFT is a trusted and closed network that bank use to communicate between themselves around the world. SWIFT is owned by the major banking institutions.

In terms of technological and technical mastery, business understanding, financial systems knowledge and timing, this heist was a perfect crime. The execution was brilliant, way beyond any Hollywood scenario. And the bank was actually pretty lucky that that the hackers didn't successfully loot the billion US dollars as they planned, but instead only 81 million.
As such, from a purely engineering perspective, studying this case is very exiting. First, I cannot help but admire the skills of the team of thieves team as well as the shape of the attack, and second, it's my job in my current company to design controls and systems preventing such attack from happening against our customers in the future.

In this article, I intend to present, explain and decipher as many of the aspects of the Bangladesh bank heist and I know.

(This article is available as a slideshare presentation here https://www.slideshare.net/JrmeKehrli/deciphering-the-bengladesh-bank-heist)

Summary

1. Introduction
2. The SWIFT network - Key Concepts
3. The attack
4. Aftermath
5. Conclusion

1. Introduction

The Bangladesh Bank hack is one of the biggest bank heists in global financial history. There have been larger scams and scandals, but cyber heists from a single bank, this takes the cake.

The heist of over 80 million US dollars sent shock-waves through the global financial system and security experts scrambled to find out how it had happened. Political and administrative authorities played the blame game, as was expected of them. Resignations were offered and statements were issued. It was a complete chaos.

The hackers managed to break into the bank's security system and transferred more than 80 million USD from the New York Federal Reserve account to multiple bank accounts located in Sri Lanka and Philippines.
A significant number of transfer requests, 30 out of 35, were blocked by the Federal Reserve, saving the bank a loss of an additional 850 million US dollars
But the five requests that managed to pass through, amounting to more than a 80 million US dollars, were devastating enough in their consequences.

Perhaps the most troubling aspect of the whole episode was that the hackers managed to hack into the SWIFT software. SWIFT, lies at the heart of the global financial system and is a network which connects majority of the world's financial institutions and enables them to send and receive financial information about financial transactions.

However, It was the bank's own systems and controls that were compromised, not the SWIFT network connection software. The SWIFT software behaved as it was intended to, but was not operated by the intended person or process. This was really a bank problem, not a SWIFT problem.

In the next chapter, I will present the key concepts required to understand the attack before presenting the shape and timeline of the attack.

2. The SWIFT network - Key Concepts

Some key concepts about correspondent banking and the principles of the SWIFT network are required to grasp a basic understanding of the Bangladesh SWIFT attack. These are presented in this chapter.

SWIFT - Society for Worldwide Inter-bank Financial Telecommunication - is a belgian company, located in Belgium, and is a trusted and closed network used for communication between banks around the world. It is overseen by a committee composed of the US Federal Reserve, the Bank of England, the European Central Bank, the Bank of Japan and other major banks.
SWIFT is used by around 11 thousands institutions in more than 200 countries and supports around 25 million communications a day, most of them being money transfer transactions, the rest are various other types of messages.

A cool introduction to SWIFT is available on the Fin website : https://fin.plaid.com/articles/what-is-swift.

2.1 Correspondent Banking

Correspondent Bank

A correspondent bank is a financial institution that provides services on behalf of another financial institution.
It can facilitate wire transfers, conduct business transactions, accept deposits and gather documents on behalf of another financial institution.
Correspondent banks are most likely to be used by domestic banks to service transactions that either originate or are completed in foreign countries, acting as a domestic bank's agent abroad.

Generally speaking, the reasons domestic banks employ correspondent banks include:

limited access to foreign financial markets and the inability to service client accounts without opening branches abroad,
act as intermediaries between banks in different countries or as an agent to process local transactions for customers abroad,
accept deposits, process documentation and serve as transfer agents for funds.

The ability to execute these services relieves domestic banks of the need to establish a physical presence in foreign countries.

NOSTRO / VOSTRO Account

The accounts held between correspondent banks and the banks to which they are providing services are referred to as NOSTRO and VOSTRO accounts (latin words for ours and yours).
An account held by one bank for another is referred to by the holding bank as a VOSTRON account.
The same account is referred as a NOSTRO account by the owning bank (the customer). Generally speaking, both banks in a correspondent relationship hold accounts for one another for the purpose of tracking debits and credits between the parties.

NOSTRO and VOSTRO accounts are really to the same thing but from different perspectives. For example, Bank X has an account with Bank Y in Bank Y's home currency. To Bank X, that is a NOSTRO, meaning "our account on your books," while to Bank Y, it is a VOSTRO, meaning "your account on our books." These accounts are used to facilitate international transactions

Transferring Money Using a Correspondent Bank

Most if not all international wire transfers are executed through SWIFT. Knowing there is not a working relationship with the destination bank, the originating bank can search the SWIFT network for a correspondent bank that has arrangements with both banks.

2.2 Transferring Money

In the scope of funds transfers, correspondent banking relationships often happen between commercial banks and central banks. This is especially useful when a bank has to process massive funds transfers in different currencies.

Imagine that a non-US commercial banking institution has to transfer a massive amount of US Dollars for one of its big customers to some other account in another financial institution abroad. It would be very inconvenient in this case to have to build up enough reserves of US dollars for this kind of transfers.
Instead of building such reserves, big commercial banks worldwide have the tendency to open a correspondent banking relationships with the US federal Reserve in New York - called the Fed - and use their VOSTRO accounts at the Fed to process such big transfers.
Such VOSTRO accounts have typically no limits and do not necessarily need to be credited beforehand. The settlement can happen afterwards, on a regular basis.

Let's illustrate this situation with 2 imaginary customers and the Bangladesh central bank:

In case the money transfer requested by a customer in a foreign currency (here USD for the Bangladesh bank) exceeds some limits or even the reserves of the Bangladesh bank in USDs, the bank decides to go through the VOSTRO account by the correspondent central bank related to the foreign currency (Here the US Fed for USD) and instruct it to proceed with the transfer.
Again, that VOSTRO account doesn't even necessarily need to be credited beforehand, the settlement can happen way later or even never.

2.3 Application Architecture (Bangladesh case)

SWIFT provides a centralized store-and-forward mechanism, with some transaction management. For bank A to send a message to bank B with a copy or authorization with institution C, it formats the message according to standard and securely sends it to SWIFT. SWIFT guarantees its secure and reliable delivery to B after the appropriate action by C. SWIFT guarantees are based primarily on high redundancy of hardware, software, and people.

Principles

SWIFT moved to its current IP network infrastructure, known as SWIFTNet, from 2001 to 2005, providing a total replacement of the previous X.25 infrastructure. During 2007 and 2008, the entire SWIFT Network migrated its infrastructure to a new protocol called SWIFTNet Phase 2.
Today the SWIFT network can be seen as a highly secured private network over Internet.

In order to have access to this network, a financial institution needs to obtain a SWIFT gateway running the SWIFT NetLink software. This is most of the time proprietary hardware running with Linux and requiring a physical security dongle storing cryptographic keys to access the network.

SWIFT also provides a whole lot of other software such as SWIFT Alliance Access that can be used by a financial institution to access the SWIFT network (always through the gateway) in a more convenient way and with higher level or simpler APIs.

SWIFT Network Security

SWIFT's security stems from two major sources. First, it's a private network, and most banks set up their accounts such that only certain transactions between particular parties are permitted. The network privacy means that it should be hard for someone outside a bank to attack the network, but if a hacker breaks into a bank-as was the case here-then that protection evaporates.
The Bangladesh central bank has all the necessary SWIFT software and authorized access to the SWIFT network. Any hacker running code within the Bangladesh bank also has access to the software and network.

The Bangladesh bank architecture

The Bangladesh central bank, at the time of the heist, was handling SWIFT connectivity from the Banking Information System to the SWIFT network using the specific SWIFT Alliance Access software running on a bridge server.
Alliance Access, integrated the way it was at the Bangladesh banks, was setup to read/write SWIFT messages from/to files on the filesystem and record transaction information in an Oracle database. In addition, confirmation and reconciliation messages were handled through a manual process after being sent to a printer.

Again, the order reconciliation process in the Bangladesh central bank was a largely manual process.
In addition, passing through the filesystem to integrate the Banking Information System and the SWIFT network is a huge security weakness. We'll discuss this later.

2.4 Introducing key SWIFT messages

As we will see in the next chapter, the hackers created a malware that generated and manipulated key SWIFT messages to withdraw the money from the Bangladesh Central Bank's VOSTRO account at the Fed.

SWIFT messages consist of five blocks of the data including three headers, message content, and a trailer. Message types are crucial to identifying content.
All SWIFT messages include the literal "MT" (Message Type). This is followed by a three-digit number that denotes the message category, group and type

The key SWIFT messages in question here were of the following types:

MT103 is used for cash transfer specifically for cross border/international wire transfer.
MT202 is the general Financial Institution transfer order, used to order the movement of funds to the beneficiary institution.
MT950 is the Final Statement report on all settlement operations with specified account within a current business day. Can be seen as the confirmation for an MT 202.

The workflow between these messages can be seen as follows:

A lot of stuff goes through SWIFT, here we focus on a really small subset of the supported message tapes, those related to transferring money.
First, the MT103 is an information message, basically announcing that a target counterparty account will receive money from an internal (or correspondent) account to be debited.
Then the MT202 is the inter-bank transfer order, it applies globally to transfer money from a banking institution to another banking institution, covering all individual account level transfer announces relating to the same target institution. There is a relationship between MT103 and MT202, they cross-reference each others (field 21 in MT103 reference MT202 and field 20 in MT202 references all related MT103)
Finally the MT950 is the extract that confirms all executed order. It is the bible and references all positions confirmed and executed by the correspondent bank. It is often an end of day extract used by banking institutions for reconciliations.

Again, when it comes to SWIFT messages processing from and to the Banking information System in the Bangladesh case, the important aspects here are:

SWIFT messages originating from the Banking Information System simply needed to be put on the filesystem somewhere to be "slurped" by the SWIFT Alliance Access software integrated the way is was integrated at Bangladesh Central Bank. In terms of security of the process, this is more that questionable.
Confirmation messages back from the SWIFT network were stored and printed. Reconciliation is a manual process from these printed messages. This is quite unusual (we'll get back to that)

3. The Attack

Summary of the attack

Capitalizing on weaknesses in the security of the Bangladesh Central Bank, hackers attempted to steal around a billion US dollars from the Bangladesh central bank's VOSTRO account with the US Federal Reserve Bank between February 4 and 5 when Bangladesh Bank's offices were closed.

The perpetrators managed to compromise Bangladesh Bank's computer network, observed how transfers were done, and gained access to the bank's credentials for payment transfers.
They used these credentials to authorize about three dozen requests to the Federal Reserve Bank of New York to transfer funds from the Bangladesh Bank VOSTRO to accounts in Sri Lanka and the Philippines.

Thirty transactions worth 851 million USD were flagged by the banking system for staff review, but five requests were granted; 20 million USD to Sri Lanka (later recovered), and 81 million USD lost to the Philippines, entering the Southeast Asian country's banking system on February 5, 2016.
This money was laundered through casinos and a little later transferred to Hong Kong.

The attack is impressive and stands out on various levels, in terms of technical means, maturity and complexity for several reasons:

Technical Mastery: the usage of a custom worm (filename evtdiag.exe) to hack the SWIFT Bridge by the bank and likely other malwares to capture the administration credentials
In-depth understanding of the worldwide financial market: both the attack shape and the money laundering scheme prove in-depth understanding of financial markets
SWIFT knowledge: in-depth Knowledge of the SWIFT messaging details is not that much spread among software engineers

Let's see how this is proven by analyzing the details of the attack.

3.1 Behaviour of the malware

The hackers used a custom version of malware to hack software called SWIFT Alliance Access to both make the transactions and hide the evidence. The hackers used a version of the malware that removed integrity checks within the Alliance software and then monitored the transaction files sent through the system, searching the payment orders and confirmations for specific terms. These terms and the responses to them were specified by a Command and Control server in Egypt.

When a message with one of the search terms was found, the malware would do different things depending on the kind of message. Payment orders were modified to increase the amounts being moved, updating the Alliance database with new values. Confirmation messages from the SWIFT network were also modified. Confirmations are printed and stored in the database. Before being printed, the malware would alter the confirmations to show the original, correct transaction value; it also deleted confirmations from the Alliance database entirely.

It's still not clear how the initial transactions were entered into the system to trigger the malware in the first place.

Again, the SWIFT network key components haven't been compromised, the malware was targeting the Bangladesh Central Bank's own bride to the SWIFT infrastructure running the SWIFT Alliance Access Software:

If an organization can't keep its endpoint secure, it leaves itself very vulnerable to being electronically robbed. That was the case here.
The bank lacked any firewalls and was using second-hand $10 switches on its network. These switches did not allow for the regular LAN to be segmented or otherwise isolated from the SWIFT systems. The lack of network security infrastructure has hindered the investigation.
It's still not known how the hackers penetrated the network, but it looks like the bank didn't make it difficult for them to do so.

How the attackers obtained administration credentials is still unclear. They might have obtained these credentials by using another malware or by exploiting a remotely available vulnerability (not impossible considering the weak security practices in place in the Bangladesh Central Bank) or it might also have been an insider job.
So far there are only speculations in this regards.

Forging fraudulent SWIFT messages

Simplifying a bit the reality, we can picture the malware as forging fraudulent SWIFT messages as follows:

The view above is a simplification of the reality. Actually, the worm was brilliantly implemented since forging from scratch consistent SWIFT announces (MT103) and Money Transfer Orders (MT202) messages would have been more difficult.
Instead, the worm was tampering with genuine messages issued by the Banking Information System and changing the amounts and recipient. This is a lot easier than blank forging.
It is still unclear for now if the initial untampered messages were simply authentic and relevant messages, perhaps duplicated by the worm, or forged through other malwares on different systems. I couldn't find clear information in this regards in all that has been published (if a reader has additional information in this regards, I would be happy to learn about it).

Just as a sidenote, whenever an institution such as the Bengladesh central bank sends a SWIFT funds transfer order, it's always in behalf of one of its customer. The SWIFT message(s) indicates the customer for which the bank requests a funds transfer.
Now of course the target correspondent bank cannot know if such customer exist, it doesn't have access to the list of customers of the sending bank. The SWIFT messages tampered by the worm could have been related to any random customer of the Bengladesh bank, this doesn't matter.
The only important aspect was that the beneficiary account and banking institution were the ones intended by the attackers.

Intercepting SWIFT confirmations

Here as well, by simplifying a little the reality, we can picture the malware as intercepting SWIFT confirmations as follows:

The malware was also developed in such a way that it was intercepting confirmation messages (MT950) back from the Fed (from the SWIFT network in fact). Confirmation of genuine orders were supposed to be allowed to pass through untampered while confirmation of fraudulent messages were supposed to be intercepted and hidden.
But the worm was buggy and while tampering with confirmations sent to the printer, it corrupted them somehow which caused the printer to crash. We'll get back to that later.

Interestingly, going as far as trying to tamper with confirmations was pure genius (even though it didn't work as expected). Had it worked, the bank might well have noticed the attack weeks after the facts since on both sides of the world (the Fed view and the Bengladesh Central bank view), positions would have been very different but yet consistent, the Fed knowing about the orders, taking them as genuine and the Bangladesh bank would have known nothing about them.
Also, one should note that transfer orders (MT202) are executed immediately. So trying to tamper with confirmations was not intended to give more chance to the transfer to succeed, it was really intended as a way to hide the theft until hopefully after the money is laundered.

The Malware

The malware, codenamed Dridex (Addendum 2020-Sep-03 - see note at the end of the article), filenamed evtdiag.exe, was designed to hide the hacker's tracks by changing information on a SWIFT database within Alliance Access and contained the IP address of a server in Egypt the attackers used to monitor the use of the SWIFT system by Bangladesh Bank staff.
It was likely part of a broader attack toolkit that was installed after the attackers obtained administrator credentials.

The malware was compiled close to the date of the heist, contained detailed information about the bank's operations and was uploaded from Bangladesh.
While that malware was specifically written to attack the Bangladesh Bank, the general tools, techniques and procedures used in the attack may allow the gang to strike again and as a matter of fact there have been attempts discussed by Reuters.

The malware was designed to make a slight change to the code of the Access Alliance software installed at the Bangladesh Central Bank, giving attackers the ability to modify a database that logged the bank's activity over the SWIFT network.
Once it had established a foothold, the malware could delete records of outgoing transfer requests altogether from the database and also intercept incoming messages confirming transfers ordered by the hackers.
It was also able to manipulate account balances on logs to prevent the heist from being discovered until after the funds had been laundered. Additionnaly, it manipulated the stream of confirmations sent to a printer that produced hard copies of transfer requests so that the bank would not identify the attack through those printouts.
This part went wrong and led the printer to crash.

More information on the malware is available in this article and this one.

3.2 Complete overview of the attack

On February 4, likely after months of preparation, organizationally and technically, gaining access to the systems, developing the custom worm, obtaining credentials, infecting the systems, etc. unknown hackers sent more than three dozens of fraudulent money transfer requests to the Federal Reserve Bank of New York asking the bank to transfer millions of the Bangladesh Bank's VOSTRO account to bank accounts in the Philippines, Sri-Lanka and other parts of Asia.

The hackers managed to get 81 million USD sent to Rizal Commercial Banking Corporation (RCBC) in the Philippines via four different transfer requests and an additional 20 million USD sent to Pan Asia Banking in a single request.

Fortunately 850 million USD in other transactions managed to be saved initially (thx to the Fed).

The 81 million USD was deposited into three accounts at a Rizal branch in Manila on Feb. 4. These accounts had all been opened a year earlier in May 2015, but had been inactive with just 500 USD sitting in them until the stolen funds arrived in February this year.

Another 20 million USD intended to be sent to Pan Asia Banking have been blocked later in the correspondent bank funds transfer routing process (thx to Deutsche Bank).

But the 81 million USD that went to Rizal Bank in the Philippines was gone. It had already been credited to multiple accounts, reportedly belonging to casinos in the Philippines, and all but 68 thousands USD of it was withdrawn on February 5 and 9 before further withdrawals were halted.
The stolen funds from Bangladesh Bank were transferred to money transfer company Philrem Services Corporation. Philrem converted into pesos some of the 81 million USD and delivered the money in cash tranches to a registered casino junket operator named Weikang Xu, Eastern Hawaii Leisure Company, and Bloomberry Hotels Incorporated (Solaire Resort & Casino).

The hackers might have stolen much more but most transfers have fortunately been stopped by the Fed and one transfer has been stopped by Deutsche Bank.

Deutsche Bank saved 20 million USD

Four requests to transfer a total of about 81 million USD to the Philippines went through, but the fifth one to transfer 20 million USD to a Sri Lankan non-profit organization was held up because the hackers misspelled the name of a non-existent NGO, Shalika Foundation, by writing "fandation" instead of "foundation".

This prompted the Deutsche Bank, a routing bank, to seek clarification from the Bangladesh central bank, thereby stopping the transaction.

The Fed saved 850 million USD

The Federal Reserve Bank did not execute 30 of the 35 transfers, worth around 851 million USD, officially due to "lack of details." These thirty transactions were flagged by the banking system for staff review.

The Fed was still tricked into paying out 101 million USD. But the losses could have been much higher had the name Jupiter not formed part of the address of a Philippines bank where the hackers sought to send hundreds of millions of dollars more.
By chance, Jupiter was also the name of an oil tanker and a shipping company under United States' sanctions against Iran. That sanctions listing triggered concerns at the New York Fed and spurred it to scrutinize the fake payment orders more closely.

It was a "total fluke" that the New York Fed did not pay out the 951 million USD requested by the hackers. There is no suggestion the oil tanker or shipping company was involved in the heist.
The Reuters examination has also found that the payment orders sent by the hackers were exceptional in several ways. They were incorrectly formatted at first; they were mainly to individuals; and they were very different from the usual run of payment requests from Bangladesh Bank.
Yet it was the word Jupiter that set the loudest alarm bells ringing at the New York Fed.

The printer error

A printer "error" helped Bangladesh Bank discover the heist. The bank's SWIFT bridge (running Alliance Access) was configured to automatically print out confirmations back from correspondent banks.
The printer works 24 hours so that when workers arrive each morning, they check the tray for transfers that got confirmed overnight.
But on the morning of Friday February 5, the director of the bank found the printer tray empty. When bank workers tried to print the reports manually, they couldn't. The software on the terminal that connects to the SWIFT network indicated that a critical system file was missing or had been altered.
The problem is deemed to be an unwanted bug with the worm, a failure in the attack if one likes, since the worm was programmed to remove confirmation of fraudulent payments from the confirmation stream being sent to the printer.
Fortunately, in this case, the Fed clarification requests and the Deutsche Bank request would have anyway alerted the bank, so even if the worm had functioned correctly, the bank would have been made aware of the attack.

When they finally got the software working the next day and were able to restart the printer, dozens of suspicious transactions spit out. The Fed bank in New York had apparently sent queries to Bangladesh Bank questioning dozens of the transfer orders, but no one in Bangladesh had responded.
Panic ensued as workers in Bangladesh scrambled to determine if any of the money transfers had gone through - their own records system showed that nothing had been debited to their account yet - and halt any orders that were still pending.
They contacted SWIFT and New York Fed, but the attackers had timed their heist well; because it was the weekend in New York, no one there responded. It wasn't until Monday that bank workers in Bangladesh finally learned that four of the transactions had gone through amounting to 101 million USD.

This article on the Fin website is magnificent and gives a lot of additional and cool information on the attack: https://fin.plaid.com/articles/anatomy-of-a-bank-heist.

3.3 Timeline of the attack

In every movie about bank robberies, timing is presented as critical. Here as well timing has been an essential concern and brilliantly mastered by the attackers.

In details:

May 15, 2015: three dollar bank accounts in the Jupiter, Makati branch of the Rizal Commercial Banking Corporation (RCBC) were opened under the names of Enrico Teodoro Vasquez, Alfred Santos Vergara, Michael Francisco Cruz and Jessie Christopher Lagrosas, with an initial deposit of 500 USD each. These accounts, which were later found to be fake, remained idle until February 4, 2016.
January 2016: The hackers installed the malware on the bank's system some time in January, not long before they initiated the bogus money transfers on February 4. This was brilliant as well since installing it too soon might have made it detected before the heist and installing it too late might not have enabled them to assess its behaviour.
February 4, 2016: Under control of the hackers, the malware broke into Bangladesh Bank's VOSTRO account with the Federal Reserve Bank of New York, ordering 35 transfers worth 951 million USD, bulk of which to be transferred to RCBC Jupiter branch.
The Fed managed to detect and block 30 fraudulent transactions but 5 transfers worth 101 million USD haven't been blocked.
February 5, 2016: The fed tried to contact the Bangladesh Bank to get an explanation about these transfers, including the 5 non blocked.
But Feb 5 was a banking holiday in the Bengladesh and nobody could answer.
February 5 to February 8, 2016: The 5 transfer are executed by the correspondent banks and the routing banks.
One transaction of 20 million USD has been salvaged. This was after an instruction to a fake Sri Lankan foundation was put on hold by Deutsche Bank, one of the routing bank, because of a typographical mistake.
But the remaining 81 million USD stolen funds found their way to 4 fake bank accounts in RCBC.
February 8, 2016: Bangladesh Bank sent a "stop payment" order to RCBC. The request means the central bank was asking to refund the stolen funds or freeze the funds if these were not transferred yet.
February 8 is a Chinese New Year non-working holiday for the Philippines.
February 9: RCBC received a SWIFT code from Bangladesh Bank requesting for a refund or putting it on hold if the funds had been transferred or freeze them for proper investigation.
Despite the "stop payment" order, RCBC Jupiter branch still allowed withdrawals from the accounts.
Money was then consolidated and deposited in a dollar account of William So Go of DBA Centurytex Trading, which was opened on the same day.
In the following days the money was laundered in the Casinos.

The timing was perfect. A unique Week-End preceded by a business holiday in Bengladesh and followed by a the Chinese New Year holiday in the Philippines, an ideal situation. The Fed couldn't get the required clarification from Bangladesh Bank on the next day and as such didn't attempt to recover the 5 orders that passed immediately.
On Monday, the stop orders sent by the Bangladesh bank couldn't be processed by the RCBC to freeze the funds since it was a banking holiday in Philippines.
In addition, the chinese new-year and the volume of exchanges in casinos at such occasion made the laundering of the money straightforward, not to mention the Philippines weak AML laws and practices.

3.4 Laundering of the money

Getting the money out is also difficult. Here the laundering scheme was both easy and magnificent. Money has been laundered through the Philippines.

The 81 million USD that was successfully stolen was sent to the Philippines to accounts at the Rizal Commercial Banking Corp (RCBC) held by two Chinese nationals who organize gambling junkets in Macau and the Philippines. The money was moved to several Philippine casinos and then subsequently to international bank accounts.
Laundering money in a Casino is fairly straightforward. One just need to touch the money as chips at any counter, loose one at any random game and then pretend one's lost enough and put it back in another account. Boom, laundered. The banking institution behind the account one withdrawn money from assumes it's been lost gambling while the other banking institution behind the account the money is put back one assumes it's been won in the Casino.

Philippine casinos are exempted of anti-money laundering law that requires them to report suspicious transactions, making them an attractive target for this kind of crime.
Plus can you imagine the amount of money transferred, spent, won and lost in Philippine's Casinos during Chinese New-Year ?
The volumes and the kind of operations makes everything absolutely untraceable.

Bamm ! Done. Money Laundered.

4. Aftermath

What Does the Heist Mean?

Even if the hackers didn't compromise the SWIFT network itself, such that all of SWIFT banks were vulnerable, it's still bad news for the global banking process. By targeting the methods that financial institutions use to conduct transactions over the SWIFT network, the hackers undermine a system that until now had been viewed as stalwart.

Who's to Blame?

Honestly only the attackers are really to blame.
But still, without such amazing security weaknesses in the Bengladesh Central Bank and with better control and stricter procedures in place at the Fed, the attack would not have been possible.
Of course, the Bangladesh Bank blames the Fed for allowing the money transfers to go through instead of waiting for confirmation from Bangladesh. The Fed counters that it contacted the bank to question and verify dozens of suspicious transfers and never got a response. Authorities at the Fed said that workers followed the correct procedures in approving the five money transfers that went through and blocking 30 others. Bangladesh Bank says the Fed bank should have blocked all money transfers until it got a response on the ones it deemed suspicious. And so on ...

The Bengladesh Bank

Aside from the loss of money, the Central Bank's governor, Atiur Rahman has resigned due to the incident. The bank promised to improve their cyber-security and ensure this kind of bank heist is prevented in the future.

The Fed

The immediate result of the breach for the New York Fed is a claim from the Bangladesh Bank for payment of lost funds and a potential lawsuit.

The Fed focused security resources on other priorities, such as preventing money-laundering and enforcing U.S. economic sanctions, officials with knowledge of the bank's security operations told Reuters. Fed officials took some comfort in the fact that SWIFT's security software had never been cracked.

The Bengladesh heist forced the Fed to invest massively in Fraud prevention solutions and better transaction monitoring systems.

Philrem services

The Philippine central bank has revoked the license of a remittance company that anti-money laundering investigators said was used to transfer some of the 81 million USD hackers looted from the Bangladesh central bank.
The Anti-Money Laundering Council (AMLC) issued a complaint against Philrem Service Corporation on April 28, accusing it of creating a fog around transactions and washing the stolen funds via a web of transfers and currency conversions through Philippine bank accounts, before moving the cash through casinos in Manila and junket operators.

The Philippines

The Philippines' involvement in the 100 million USD Bangladesh Bank heist, which has risked its return to the FATF gray list, showed the urgency of putting more teeth into the Anti-Money Laundering Act (AMLA).

The law, which was first introduced in 2001, left casinos out of the list of entities required to report suspicious transactions to the AMLC. There were efforts in the Senate to include this provision in the amended AMLA in 2013, but this was blocked by some lawmakers and casinos lobbies.

5. Conclusion

If the hackers had indeed managed to get away with the terrifyingly large amount of 1 billion USD, this would have easily been the biggest bank heist in history, not to mention cyber heist.

Interestingly, these kinds of attacks will be increasingly common and if banks aren't updating their security processes and maintaining their network infrastructures, and the success rates of these attacks will only go up. Worse still, if hackers have access to banks and can manipulate funds, any businesses that partner with those banks is also at risk.

Imagine the following, if the worm had functionned correctly and not blocked the printer, if the Deutsche bank didn't find the typo, if the Fed didn't become suspicious because of the Jupiter keyword, the attack might have been a complete success. Not only the attackers would have successfully withdrawn almost one billion US dollars from the Bangladesh bank VOSTRO account at the Fed, but the attack might have been noted only weeks or months after the facts.

Finally, imagine that the same attack succeeds against a american or an european bank. In the US and in Europe, the SWIFT interfaces are integrated in an STP (Straight Through Processing) way. There is no such thing as manual reconciliation from some papers printed on a printer. The handling of confirmations and position reconciliation is mostly completely automated.
As such, the same attack succeeding in Europe for instance might take months to be discovered and uncovered, only a the moment the big position reconciliations between NOSTRO and VOSTRO accounts in correspondent banks are triggered.

And this is where it gets really funny. Everybody always had the illusion that SWIFT was so secure, so sure. It gave banking institutions worldwide the illusion that everything related to SWIFT is just as secure. But if the network itself is pretty secure indeed, the specific bridges and interfaces linking the Banking Information Systems to SWIFT can be very weak, as shown by the Bangladesh Heist.
Today european and US banking institutions and central banks are very worried and investigating transaction monitoring and security solutions to prevent such misadventure to happen to them.
Again the same attack in Europe would be a much bigger disaster.

Now another funny story to conclude this article: imagine a similar hack between two banks in Europe and imagine that one of them suspects something ... They would use SWIFT again to reconcile their views of the truth (MT109 and MT999).
These messages can be hacked just as well, in which case the theft may remain uncovered for months.
This is really hilarious.

(This article is available as a slideshare presentation here https://www.slideshare.net/JrmeKehrli/deciphering-the-bengladesh-bank-heist)

Edit Sep 3rd, 2020

At the time of writing of this article, it was a common belief in the group of people I was discussing this with that the main worm used for the heist (EvtDiag filename) was a custom version of the Dridex worm.
It has been brought to my attention that nothing confirm this hypothesis, on the contrary multiple experts and studies show EvtDiag had nothing to do with Dridex.
So even though some other sources are clearly pointing Dridex as (one of) the the worm(s) used in the attack (e.g. http://www.straitstimes.com/business/dridex-malware-linked-to-bangladesh-heist), this should be taken cautiously.

niceideas.ch

Artificial Intelligence and fraud prevention with Netguardians' CTO, Jérôme Kehrli

NetGuardians' 3D AI Technology

A focus on customer behavior

The three pillars of 3D AI

Fine-tuning and machine learning

AI - opportunities and challenges for Swiss banks

Artificial Intelligence and it's potential in the banking business.

What about Swiss banks ?

Dissecting SWIFT Message Types involved in payments

1. Introduction to SWIFT

1.1 Key SWIFT aspects

1.2 Correspondent banking

1.2.1 Correspondent Bank

1.2.2 Transferring Money Using a Correspondent Bank

1.2.3 VOSTRO and NOSTRO accounts

1.3 Key SWIFT Message Types

1.3.1 Detailed presentation of key SWIFT messages

1.3.2 Typical situation and use cases in banking institutions

1.4 Serial and cover payments

1.4.1 Cover method details

1.4.2 Serial method details

1.5 SWIFT Message Structure

1.6 SWIFT BIC Code

1.6.1 Structure of the SWIFT BIC Code

1.7 Other specific details

2. Dissecting key SWIFT Mesages involved in payments (Funds Transfers)

2.1 SWIFT MT101 Detailed Analysis

2.1.1 MT101 Introductory examples

2.1.1.1 MT101 Example 1: Simplest case

2.1.1.2 MT101 Example 2: beneficiary with another institution

2.1.1.3 MT101 Example 3: Multiple payments in MT101

2.1.1.4 MT101 Example 4: Payment from a subsidiary account

2.1.1.5 MT101 Example 5: Fund repatriation

2.1.2 MT101 Parsing and Data Mapping

2.1.3 Additional notes on MT101

2.2 SWIFT MT103 Detailed Analysis

2.2.1 MT103 Introductory examples

2.2.1.1 MT103 Example 1: Simplest case

2.2.1.2 MT103 Example 2: more realistic example

2.2.1.3 MT103 Example3: forwarded serial message

2.2.1.4 MT103 Example 4: Announce message (cover method)

2.2.2 MT103 Parsing and Data Mapping

2.2.3 Additional notes on MT103

2.3 SWIFT MT202 Detailed Analysis

2.3.1 SWIFT MT202 Introductory Exampkes

2.3.1.1 MT202 Example 1: simplest case

2.3.1.2 MT202 Example 2: other bank case

2.3.1.3 MT202 Example 3: routed message

2.3.2 MT202 Parsing and Data Mapping

2.3.3 Additional notes on MT202

2.4 SWIFT MT202 COV Detailed Analysis

2.4.1 MT202 COV Introductory examples

2.4.1.1 MT202 COV Example: Cover payment

2.4.2 MT202 COV Parsing and Data Mapping

2.4.3 Additional notes on MT202 COV

3. Conclusion

Interview about NetGuardians and fighting fraud in the digital era

Artificial intelligence for banking fraud prevention in the digital era

Digital urgency

1. The customer experience

2. Advanced analytics, operational efficiency and service customization

3. Prevention of bank ingfraud and anti-money-laundering

AI ​​against banking fraud, a bit of history

Return of Experience, our approach at NetGuardians

Customer experience, the machine in contact with customers

Artificial Intelligence for Banking Fraud Prevention

1. Early times, the 2000s

2. The late 2000s - fraud costs rise

3. The reality of fraud changes dramatically

3.1 The Bangladesh Bank heist

3.2 The retefe Worm

4. Facts and Projections

5. Historical systems are beaten

6. Artificial Intelligence comes in help

7. The Machine can do better

8. Even further

9. Conclusion

10. Artificial Intelligence vs. Augmented Intelligence

11. AI Pillars at NetGuardians

AI against banking fraud, a bit of history