Digital banking powered by an API-led architecture

API-led architecture

As mentioned in my first post in this blog series, one of the 10 largest banks in the world found itself burdened with a complex, tightly coupled technology environment, leading to operational inefficiencies, a risk of missing out on new sources of revenue, and losing market share to its competitors.

The bank needed a solution that would enable innovation, increase the speed of project delivery, and improve the quality and performance of IT operations. The bank’s technology leaders determined they could best achieve these goals by connecting applications, data, and devices with MuleSoft’s API-led connectivity approach

The point-to-point integration challenge

Prior to adopting MuleSoft, the bank met customers’ digital needs through a complex web of tightly coupled systems of record. Applications were connected through monolithic web services or point-to-point through custom code. As the bank made acquisitions and developed new applications on top of pre-existing code, complexity increased. As a result, applications became even more tightly coupled, and internal dependencies across applications multiplied. Because monolithic integrations provided no visibility into what data was traveling from system to system, how it was being transformed, or what logic was employed, the technology landscape became riddled with duplications.

Teams of system experts were required to maintain dependencies. Any effort to change systems required their participation, resulting in significant bottlenecks. The time it took the central IT team to make changes to existing applications and develop new ones was extended 5-6 times over, making it even more challenging to serve the growing demands of the business in addition to the expensive maintenance of these applications.

The bank recognized a need to adopt a new strategy to address the challenges of its legacy technology environment, reduce its dependence on system experts, and increase its ability to deliver new technologies faster. Rather than continuing down the path of connecting legacy systems to modern endpoints through point-to-point custom code, the bank concluded this strategy would lead to even tighter coupling across its application stack and make new projects even more time-consuming to deliver.

“We want to avoid point-to-point connectivity. We didn’t want to do an implementation for each service we’re developing with its own rules.”

The bank’s senior vice president of IT and the leader of the initiative

Instead, central IT aspired to surface legacy system functionality to line-of-business teams through decoupled, reusable services that could be easily discovered. As such, the bank changed its approach to integration from “connecting point A to point B,” to “unlocking point A so any other point can consume assets from point A.”

The bank’s new architecture

The team envisioned a three-tiered, API-led architecture, implemented with MuleSoft: 

API-led architecture
API-led architecture
  • System APIs. Underlying all IT architectures are core systems of records. System APIs are designed to unlock difficult-to-access data, such as demand deposit account numbers or master customer identifiers, while hiding the complexity of these systems from the user. With system APIs, banking divisions are able to share core system data and functionality in a consistent, managed, and secure way. Downstream systems are insulated from any changes, and system experts are no longer needed for every project as system APIs can be reused. 
  • Process APIs. Process APIs abstract away system complexity by allowing one to define and share a common process, such as aggregating account balances or assessing creditworthiness. Lines of businesses can manipulate data received through system APIs and build on them by combining APIs and/or building new APIs on top of them. The decoupling of system APIs from process APIs allows central IT to maintain governance over core capabilities while federating servicing and product decisions to the lines of business. 
  • Experience APIs. Experience APIs are the means by which data can be reconfigured so that is can be most easily consumed by the intended audience. Experience APIs also encapsulate business logic managing authentication, authorization, and auditing. They speed up development by allowing app developers to consume underlying assets without having to know how the data got there.

The three-tiered API architecture is strategically designed to standardize three key dimensions that drive business operations: data (via system APIs), processes (via process APIs), and channels (via experience APIs). By encapsulating each dimension into an API that can be discovered and reused across all lines of business, banks can begin rationalizing service delivery. Data, once sprawling and duplicated across the enterprise, can be governed and managed. Processes that were unique to each line of business can be harmonized and redesigned around the customer experience. Channels that were once disjointed can be unified.

Reusable APIs capabilities
Reusable APIs enable a bank to break down organizational silos and transform into a digital platform

To fully illustrate this transformation, I will highlight the below four bank initiatives in the coming blog posts.

bank digital transformation initiatives timeline
  1. Mortgage lending transformation: Deliver a single mortgage servicing platform to serve as the central source of truth for loan data and processes across the mortgage lifecycle.
  2. Collections and recovery consolidation: Consolidate collections and recovery operations into a unified debt management experience across multiple lines of business (e.g. mortgage, auto loans, credit cards, etc.).
  3. Client and customer data platform: Create a central source of truth for client and customer data that would enable a single view of the customer across LOBs and omnichannel experiences. LOBs initially decided not to leverage Anypoint Platform or MuleSoft’s API-led connectivity approach; after seven months of delayed timelines and minimal success, the project team realigned its integration strategy to API-led.
  4. Marketing and sales acceleration: Unify Salesforce instances across lines of business to accelerate marketing and sales and drive growth.

To discover how the bank’s initial rollout of MuleSoft’s Anypoint Platform and API-led connectivity led to its application network, check out our whitepaper.



We'd love to hear your opinion on this post


One Response to “Digital banking powered by an API-led architecture”

  1. Hi Angie,

    Thanks for a very interesting post.

    There are a couple of questions though that I’ve got reading your article.
    Based on the diagrams and description, for this transformation, the layered architecture style was used as a base.
    If I understand correctly, various front end systems will communicate with Experience APis layer and APIs in that layer will use Process APis that, in their turn, will connect through the Service APIs layer with the data sources (all that probably using API orchestration on any of those layers for composite services).
    If that is correct, then in the most simple case there will be 3 consequent API calls required to provide/manipulate the data. Assuming that layers are isolated and APIs from different layers communicate through the web protocol it might create a couple of risks, like potential performance hit due to latency, multiple points of failure for even simple scenarios, API management complexity due to potentially complex service orchestrations and/or choreographies. Depending on the level of services granularity and many other factors those concerns could be more or less severe, it just interesting how did these typical concerns for any microservice-based architecture were handled in this case.
    Thanks for your answer, in advance.