Recent events in the international payments world have highlighted yet again the confusion over SWIFT’s responsibilities in the payments chain.

SWIFT was created to send payments instructions from a sender and a receiver.  Over the past 40 years that basic role of SWIFT has not changed.

SWIFT’s major contribution to the payments world was the work it carried out in messaging standards and developing different message types to match the needs of the users.

SWIFT’s role simply put was to define the format of a date, but not to determine whether it was the right date.  The formats for account details were also developed, but not the veracity of the data entered.  SWIFT determined that account number had to be of a certain length, but does not and never has checked to make sure the account number is real.

In the same way SWIFT determined that the name of the beneficiary should be present, but they do not check that ‘John Doyle’ is a bona fide person; who would!

Why not?

To answer that question we have to go back to the roots of SWIFT and I want to remind you why SWIFT was created in the first place.  There was a model of banking in the international sector called correspondent banking.  This concept has been around since the days of the Lombard family who invented banking.  In simple terms correspondent banking was the introduction by one customer of a bank, say in London to another bank in Berlin.  The correspondence was a reference and introduction between the banks that the holder of the correspondence was a good person and could be trusted to do business with.  The result was a bilateral correspondent relationship which involved holding complementary balances and an agreed list of fees and services each party would perform for the other based upon the customers banking requirements.

The payments value chain has always remained the same; customer A asks Bank A to transfer money to pay for goods sent by Customer B to Bank B.  Upon receipt of the instruction Bank B debits the appropriate account pays Customer B and then advises Bank A the transaction is complete.  In 400 years of banking that scenario hasn’t altered and except for changes from correspondence by mail, to telex and then by computers and the internet, the basic service hasn’t changed.  For 40 years SWIFT has provided a secure, resilient and reliable way of assisting the financial services community to continue to provide this simple service to their customers.

SWIFT basically promised that a message delivered to them by a bank would be transmitted to the receiving bank and by the use of authentication and verification would ensure the message was transmitted as received by SWIFT and delivered unaltered to the receiver.  Simple and it works.

At the time SWIFT was created the world was a different place.  International payments were in the main made manually and from large, secure telex rooms with high security.  As the world changed and we saw the growth of PC’s and the internet the control over these payments devolved to the departments that were responsible for their creation like the trade finance or cash management teams; and as technology allowed it they devolved further to the branches.

The other day I was able to go into my local HSBC branch and transmit funds to settle a Chinese PO and the payment details were entered in the branch, authorised there and then sent by the HSBC network to their SWIFT department who then transmitted the instruction to SWIFT.  But, as I said no money was transmitted.

Money is transmitted by user to user transfers by issuing instructions to debit user accounts or customer accounts held by the receiver.  The idea behind correspondent banking is that banks hold deposits in the banks with whom they do business and the SWIFT instructions merely instruct the receiving bank to debit those accounts, so SWIFT is not a money transmission service.  SWIFT transfers instructions from the sending bank to the receiving bank to move funds that the sending bank already has on deposit.  And that is where that lovely phrase Prudent Banking Practice comes in.

If a bank receives a SWIFT instruction to transfer funds it is totally incumbent on the receiving bank to ensure that the funds are available and that the bona fides of the customer and the account details are correct, hence the big concern at the moment over |KYC and AML checking.  If you haven’t established a correspondent banking relationship by exchanging bilateral keys then you cannot send a message to each other, SWIFT will stop it.

It’s the same if you haven’t funds in your account, that’s a bank problem not a swift one.  When I worked for SWIFT my colleagues and I had it drummed into us that SWIFT does not replace product banking practice and as payments get faster and faster around the world and we rely more and more on automation, then it becomes even more incumbent on SWIFT users to understand they, and they alone are responsible for their own security.  SWIFT gives it’s users tools, services and products to help, but they just reinforce the fact that the buck stops with either the sender or receiver, not SWIFT.

The two weak points are the user interface used to connect to SWIFT which is operationally controlled by the sender and receiver, and the bank’s own staff and the bank auditors should be busy developing processes and procedures both manually and automatically that mitigate the risk of fraud in these two areas as much as possible.

It’s interesting to note that most of SWIFT’s internal security is in place to stop messages being read to protect confidentiality, as it is commonly accepted that the checks and balances in place are sufficient to stop a fraudulent message being introduced into the SWIFT infrastructure.

So, to the recent press about the SWIFT network being hacked; hum!

Now about regulating SWIFT; that’s a whole other issue and you should watch this space …….