A small, private bank in London was looking to move its BizTalk Server on-premises payments system to the cloud.
What was the problem?
The bank typically processes only 14 million payments per year, but with substantial amounts per transaction. As the bank serves high net worth individuals, a considerable number of transactions tend to be of the order of 7 figures (millions of pounds) – with payment sizes growing 10% each year. When processing amounts like this, the need for security and auditing is paramount.
345 Technology was engaged to create a proof of concept (PoC) for the bank’s payments platform, a task we were able to deliver in record time. All of the bank’s systems were based on an on-premises setup, yet it wanted to deal with increasingly cloud-based payment providers. This led to a requirement for the bank to move to a modern, event-driven payments system that could be cloud native.
Requirements
Given the size of individual transactions being processed, the key requirement was for a system that gave the bank the best possible security and auditing capabilities, to help them meet their legal and fiduciary responsibilities.
The bank had various other requirements for this project, the main ones being as follows:
Cloud first: a modern, cloud-based payments platform to replace previous operations handled via an on-premises BizTalk Server installation.
Low-code: the bank specifically wanted to reduce the amount of code that needed to be written and maintained. As much as possible, they wanted to use Azure resources that needed only configuration or were regarded as low-code.
Speed: support for accepting and rejecting of payments from payment providers in an extremely brief period, in the order of a few seconds (ideally a sub-second process).
Immutability: payments had to be treated as immutable, meaning that the same payment could not be applied twice.
Modularity: the bank wanted a dynamic system consisting of a framework of building blocks that could be added to over time, to support more payment methods in future.
Auditability: every action performed by the platform must be recorded, in an audit log, for later examination – this is a fiduciary requirement, and was required to support any payment tracking requests from a customer.
Traceability: payments could never be allowed to be lost by the system.
Cost: there needed to be a limit imposed on the cost of the platform regardless of the number of transactions being performed.
Solution
The bank’s existing processes were complex, and our work needed to integrate with their systems with as little interference as possible. This posed quite a challenge given the requirements of the project to modernise their setup.
Our work started with a detailed review of the bank’s requirements and existing architecture. An event-driven microservice system would have been ideal, but BizTalk makes this hard to implement, so we turned to Azure Integration Services.
We created a PoC made up of the following:
Azure Integration Services: with API management via an external mediation layer.
Audit listening: an event-driven mechanism, powered by Azure Event Grid, meant we could plug in an audit listener to record all events to an auditing database. The audit would allow the bank to track every event, with all messages being signed.
Azure Logic Apps: used to create workflows for processing payments in a generic format, including handling exceptions and moving payments out of the main flow.
Azure SQL Server: used to store data in an encrypted fashion e.g., payments that have moved out of the normal payment flow.
Azure Monitor: to track issues and notify teams if there was a payment exception.
Additional workflows: to handle late messages and responses for retrying payments after failure.
What was the result?
We provided the bank with an Azure-based PoC that demonstrated key elements of the requested design, giving them confidence that we could meet all their requirements, particularly in the areas of auditing and safety.
We used Logic Apps Consumption, which used an integration service environment for security and privacy. Our suggestion would be to migrate to Logic Apps Standard so that we could run everything in secure environment, and which would not require an integration service environment.
Our reuse of Azure components meant we were able to deliver our PoC in record time – a mere 2 weeks.