Unraveling how to build a bank-SWIFT Messages Autoclient automation with cloud connectivity
This is an introduction to banking series which tries to explain the things I did and why. I don’t know everything so please feel free to alert me if I am wrong or there is something better as banking lacks a knowledge pool.
I mainly go into the transactions side of banking related to international transactions in this post. As for the Asset side, that is more complicated and I will expand on all of it slowly.
Introduction
As this is my first medium post, which I decided to pursue as a way to share my knowledge, I will introduce myself:
I am the founder of a conglomerate that specializes in building end to end infrastructure for banks. I have worked on projects which involved getting international banking licenses in all major jurisdictions, crafting internal and external policies for corporate banks, and creating IT framework which resolves the bottle necks of the world, and much more.
In this whitepaper, I will usher you to this covert world and one of it’s challenging flaw that we solved, while acquainting you with one of the core arrangements which majorly influences the cash flow around the world.
My aim is to simplify banking and penetrate the jargon with a series of quality posts because of the non-existence of the documentation, even when dug through a bunch of 200+ page whitepapers. I also aim to publish a book to enable people to get an idea of how banks really work, if these posts pique the general interest of the readers.
Our Solution
In 2020 my team and I strived to design a customized infrastructure solution for the SWIFT messaging system based around the non-cloud provision they offer. The architecture is based around custom connectivity between their Autoclient system and AWS cloud services which can be translated into other cloud platforms.
Our system provided a faster, non-hackable ledger, which terminated SWIFT’s core vulnerabilities in their cloud offerings, and which ensured more scalability into local transactional structures like SEPA.
Why did we do it? While SWIFT is used for a majority of the international transactions, there are other systems with the likes of SEPA for Europeans which are within individual jurisdictions. Also, the traditional cloud offering SWIFT rolled out is achingly filled with gaps and dated technology, and building a customized infrastructure with virtual management is considerably secure while going through an offline switch. Furthermore, that data pipeline can streamline administration activities through the cloud in multiple systems.
For people uninformed about banking, Autoclient is a system that connects with the SWIFT network, responsible for sending messages among banks around the world about transactions. We are talking about the conventional system which requires an encrypted USB key to access and has automation in terms of sending FIN formatted files containing MT format messages to other banks and network institutes. What we created was better than SWIFT’s Alliance cloud offering, not to mention significantly more impregnable, as an average bank runs the risk of getting a major hacking attempt every 6 hours and connecting to a cloud without a defensible infrastructure is not a viable option. Having that move simultaneously was an impediment we successfully triumphed over. A case in point is Bangladesh’s famous hack, which was visible while most hacks don’t even get media attention in our banking sectors. Even the famous banks in Australia, have all been hacked, and due to potential defamation law suits I shall not name them, but one of the famous ones is very easily penetrated. There data is literally available online if you are studious enough to search, and they pay inefficient technology teams to keep there legacy systems going because they do not trust any better.
Our solution, which I will discuss in depth, allows you to bridge custom web platforms with the SWIFTs auto client system using the state-of-the-art technological infrastructure. Our systems facilitate all of your clients and admin requirements through our customized banking solutions, leaving you with just the hassle of your front-end development. We have created APIs for internal incoming & outgoing transactions, SWIFT outgoing transactions, SWIFT incoming transactions, forex exchange system (Correspondent settlement capability), fast KYC, transaction log creation system, total bank balance, sending SWIFT outgoing messages (non-transaction), and SWIFT incoming messages (non-transaction). We have also adopted advanced data pipelines, which further eases your machine learning performance if you require it. Besides, we have a core banking suite for Asset side banking. While we offer the aforementioned services, I will dive into the solution we created connecting the Autoclient. Saving the best for last what we have done is accomplished the gold standard of security and due to security reasons I will only go at a higher level overview for you to understand the core of it.
Security — Technical
We have a bi-layered ledger on the cloud pipeline with all administration being conducted in two different servers hosted through VPN’s in an Oracle DB on the local server. An image is being placed on every interaction, with codebase being replicated every X epoch- standardized at 5-minute intervals. We place switch ports to defend against attacks by having a custom scanner which analyses out of the ordinary ledger changes or code changes, and reverts to a previous state in a different server. We also maintain a hyperledger, which searves as a storehouse of all informational transactions with a hybrid approach to cloud infrastructure.
We have multiple data pipelines, double encrypted with all our data being tokenized. We never directly connect to the local server. Instead a manual wiring switchboards the virtual state with live SWIFT infrastructure. When a new state reflects through the pipelines we send it through a decryption and state check, then switch it through from local hardware in two different locations. There is another middleware check from a cloud state which matches the two states and then funnels through our pipeline to the SWIFT server and uploads the contents or sends them in the opposite flow for an incoming transaction.
A security of such degree coupled with a blend of multiple programming languages and a clearance check when transactions are cleared, shuts all common susceptible loopholes and allows it to be an effective and impenetrable offline cloud system. As we have a cloud based functionality which only handles a virtual system where real transactions are effectively based in an offline data warehouse in a secure vault.
We also have internal and external business and operational policies to ensure social vulnerabilities do not transpire, including having multiple backups and automatic scanning systems for invoices and other information implicated in the message, and creating economies of scale in terms of security as we keep key data ledger.
Solution Details — Technical
SWIFT requires the setting up of an independent local machine responsible for sending inter-bank messages in correct formats which in this case are MT messages, where MT103 message type format is the most common message type to send transactions through.
SWIFT has its own admin system, with Alliance Lite 2.0 and similar products. Its classic auto client system aids in sending and receiving messages outside the manual administration system and provides an opportunity for expandability by bulk clearing FIN formatted files allowing multiple transactions (Messages) to go through at once.
We have currently built a system capable of generating correctly formatted messages from a range of inputs, admissible by the SWIFT system.
Outgoing AWS — Technical
Our software syncs with the SWIFT’s auto client emissions folder and allows it to receive FIN files formatted to MT requirements from the fields provided by the client in the front-end. For the Windows systems, we use the windows task manager to ensure uninterrupted network connection but generally prefer only linux based systems, preferably Kali Linux due to Windows being un-secure and we can close obvious loopholes in Kali, such as the cow vulnerability. Generally, we receive MT103 type messages communicating transaction amounts. While we have a separate system to process just MT103 types, for other message types there is a different API allowing segregation of logs in the admin panel, as nearly all of the message types are dispatched through bank administration.
Figure 1: Process flow for API showing flow from posted fields in API to SWIFT operator verification
For our AWS solution, there is an S3 bucket, which stores all your FIN formatted files waiting to be synced after a set timer. There is sequenced decryptions and double layering. To send requests, you just have to post an API request with a unique ID to our API gateway, which automatically processes the request. It will send the FIN file to your auto client system which will then archive it and show up in your operator system for verifications. You can set up a bipartite verification, one in the admin panel of your web platform, and another in your swift system for your operator verification. For Auto Client, the configuration is modifiable to accelerate the deployment process from admin verification to operator verification. All of this happens at a high frequency capable of handling millions of activity nodes at the same time.
As for high frequency and ML heavy tasks we use fast data pipelines like KAFKA and Spark with Aerospike as the database, which makes it infinitely scalable when the load balancing is done correctly with partitions allocated in a set framework.
Incoming AWS
For incoming messages, the incoming folders are synced with the S3 bucket in AWS, where our FIN files are pushed. Our parser picks up the file, reads the various message types and puts them in the correct fields to be displayed in two incoming tables, one for MT103 and another for all other types. Our API can then further trigger pending, approval, and rejection mechanisms and can be integrated with our balance triggers which facilitates you to create transaction histories and balance creation.
Figure 2: Process flow for API showing flow from posted fields in API to SWIFT operator verification
To access this, you just have to set up the sync and relevant software on your local server, and all the files will automatically sync and send the data directly to the tables in a database that you can query and access.
This is my first Blog/ White-paper made for public viewing, I hope you enjoyed the read and if you have any questions please feel free to ask. I will keep sharing my knowledge with you to help anyone who owns a bank or wants to know how to build it on what goes into a core banking system which doesn’t short you of a million dollars for an outdated infrastructure filled with gaps and inefficiencies.
Leave a comment or email me at abhishek@vastdreams.com if you have any queries related to this. I would really appreciate what you think about this and any feedbacks as I am still exploring how to go about sharing this information. If you want you can even post below what you want me to write about in banking next and disclose some solutions we have worked with.
Disclaimer: I do not take any responsibility for any use of this information in any way form or shape. Banking is a very delicate field where mistakes are disastourous, and if you want to build, advice or run a bank you need to have a team and professionals who can do it. I have never gone and worked with a bank without being surrounded by experts in various areas, with credentials such as being directors of international banks, and I advice anyone venturing into this indusry to always take advice and make sure to double check everything. You are dealing with people’s life savings often, so please be responsible in the use of this information. I have also been careful to avoid mentioning the obvious loopholes the internal banking directors are aware of with our current way we do banking which leaves vulnerabilities as with any system. This has been done to avoid intentional harm from unscrupolous individuals. This information is from our Intellectual Property and use of this for commercialization without authorization will be pursued legally. This has been done in a good faith to pool the knowledge in this sector.
Authored By: Abhishek Sehgal
“Small — but consistent steps build an unstoppable momentum, which is the key to manifesting dreams into reality.”
Edited By: Prabali Chattoraj
