Modernizing a Financial Transaction Infrastructure for Cross-Border Expansion
A global bank rolled out a highly scalable, cross-border payment system.
The financial services sector, and banking and payment processors in particular, are in a period of rapid technological change. All companies in the sector are affected to one degree or another, but the ones that are embracing the changes and moving forward most aggressively are differentiating themselves from their competitors and gaining market share.
Some of the many changes that are affecting the industry include:
- Payments are increasingly going digital. Digital wallets are no longer just for the early adopters; they are becoming more mainstream.
- Real-time payments are making up an increasing share of the overall payments space.
- Peer-to-peer payments are proliferating, not just locally but in cross-border and cross-currency transactions.
- Machine learning (ML) and artificial intelligence (AI) are being increasingly used in the payments space, for applications such as fraud detection and payment network selection.
A large multinational bank headquartered in the Asia Pacific region was looking to build out its payment processing infrastructure. With over 30 different payment offerings in their portfolio, and clients across 40 countries, the bank is an established global leader in Asia, the Middle East, and Africa.
With a wide range of payment solutions in their portfolio and many underserved markets in the geographic regions where they operate, the bank saw fertile ground for expansion. They knew their current application architecture was not flexible enough to handle the new demands. Their markets required operating in multiple countries, with multiple currencies, languages, and regulatory requirements. The effort required to adapt their software to move into new markets made it cost prohibitive to take advantage of the opportunities that were available. To unlock the capabilities needed to tackle new markets, they undertook a digital transformation project to build the foundation upon which new applications could be built.
At a high level, management established four key objectives to measure the success of the digital transformation project the bank would undertake to enable them to capitalize on the new market opportunities they saw. These objectives were:
- Reduce the length of development cycles for the payment systems products from the current six months down to a cycle of one to two weeks per release
- Add scalability so the new system had the flexibility to grow on demand with increased performance to continue meeting their demanding SLAs
- Maintain five nines (99.999%) availability
- Ensure security through the use of encryption (for data-at-rest and in-motion), and ensure conformance to applicable security standards and governance requirements of the many different territories where they operate
The bank was looking to expand their online payments business, but was hampered by the inflexibility of their existing solution. The existing application architecture could not scale up to meet the demand of larger customers that could unlock the highest potential return on their technology investments. In addition, the legacy code was difficult to extend and evolve, so that adding new features or adapting to facilitate entry into new markets could not be done in a timely fashion – release cycles of the monolithic application were generally six months in duration.
One of the client banks in Hong Kong had a requirement for a 50x increase in transaction speed, so this became one of the criteria for evaluating the performance of the solution. Even if large investments were made in upgrading the hardware environment for the application, the bank was doubtful that such an improvement would be possible with the existing software architecture.
To enable the bank to move aggressively into new markets to capitalize on the opportunities they saw, they re-architected their monolithic application into a set of microservices. The benefits of a microservices architecture aligned well with the bank’s need to be more agile. They could have smaller, more nimble teams developing each service, and the loosely coupled services could evolve independently to support new business opportunities or adapt to changing conditions. Hazelcast’s lightweight footprint and deploy-anywhere flexibility make it a great choice for moving to cloud-native microservices-based architectures.
The new architecture addressed all of the key success factors that had been determined up front:
Speed: To iterate quickly on new applications and features, the manual deployment process was replaced with an automated CI/CD process. Hazelcast’s familiar API, based on Java collections, means that developers didn’t spend time learning new ways of doing things, and were able to begin development right away using Map and other familiar classes.
Scale: Hazelcast’s elastic scalability means that capacity increases can be done in a zero-downtime fashion, simply by bringing new nodes online. Data structures will be rebalanced to the new node configuration without interrupting ongoing processing.
Stability: To achieve the required up-time, the new architecture featured automatic failure detection, auto-healing systems, and blue-green deployments.
Security: Industry standard security protocols, such as TLS/SSL, encrypt data at every step of the way to meet strict compliance requirements. The built-in security features of Hazelcast protect sensitive customer data, making it easy for the application developers to provide the required security features without developing a lot of customized security code.
The new microservices-based architecture consisted of five services that were interconnected via an intelligent router.
- As transactions enter the system, the Kafka event bus publishes them to a payment processing topic, to which the first stage of the microservices pipeline is a subscriber. This first stage is an ETL stage that transforms the transaction into the format used by the payment processing microservices, and stores the transaction into an in-memory map for further processing.
- The second microservice is the main processing service. Here, a number of processing tasks are performed in parallel. One of the most compute-intensive of these is fraud detection. There are thousands of rules that are executed by the system for each transaction that comes through the processor. This would not be possible without the low-latency access to data provided by the in-memory architecture of the system, as well as the “computation in the grid” capability that allows processing to be performed where the data resides to eliminate the latency that would be introduced by network access to the data. As fraud rules complete, the memory-resident transaction state is updated. At the same time, other rules are executed to optimize the selection of the best-fit payment network to route the transaction through to minimize costs and meet various transaction-specific requirements (which may relate to currency, transaction size, or other factors).
- At the completion of processing, the transaction is picked up by the account storage service to update account balances, post the transaction to the account log, and keep track of other account-related specifics related to the transaction.
- The message router is then invoked to build messages in the appropriate format for the selected clearing house and payment networks. All of the required information is gathered and the message assembled.
- Finally, the message dispatcher is invoked to post the message back onto the Kafka event bus for delivery to the appropriate destination payment gateway.
Each of these microservices is a client to the shared Hazelcast cluster which serves as a common data layer for all services. A separate cluster stands by as a failover system to support disaster recovery scenarios, with the Hazelcast WAN Replication feature keeping the backup in sync with the primary cluster. Other Hazelcast features such as Rolling Upgrades (for upgrades to the Hazelcast software) and Blue-Green deployments (for upgrades to the application microservices software) enable new software rollouts with zero downtime. With these high-availability features, availability is 24/7 with 5 nines reliability.
In rolling out the new solution, the Hong Kong market was chosen as the pilot as that market had the greatest demand for a fast payments solution. Following the successful deployment in Hong Kong, the solution was then deployed to India and Singapore, and eventually across all 40 target markets. An ACH (Automated Clearing House) solution was deployed as the second major application.
The initial deployment of the fast payment system was scaled to process 14,000 transactions per second, with latency of less than 20 milliseconds per transaction. This performance level met the customer requirements, but the application has the ability to scale up to 100,000 transactions per second to accommodate future growth.
A combination of in-cluster backups and remote data replication using the WAN Replication feature of Hazelcast provides the reliability to run a 24/7 real-time payments operation. The fast payments solution was recognized by The Banker with their “Innovation in Digital Banking Award” for the payments category for 2020. The Banker has been a leading source of economic and financial reporting for the banking industry since 1926.
The use of Hazelcast has helped the bank to significantly reduce cycle time, allowing them to deploy in weeks new applications or features that would previously have taken months. The intention is to continue to improve on this, with the goal of standing up new features or applications in just days.
With this flexibility, entering new markets and introducing new payment products can be done at a pace that wasn’t possible with the old technology stack. As banking becomes increasingly digital, mobile, and cross-border, the bank is well positioned to take advantage of new opportunities and accelerate their growth.