How standardized APIs enabled efficiency, speed, and security for a global top 10 bank

Standardized APIs- efficiency, speed, security

One top 10 global bank’s efforts to improve its IT operations was quickly coming to fruition; following the success of applying API-led connectivity to mortgage lending, its IT team embarked on another project to unify collections and recovery experiences. 

Leveraging reusable assets

This project was more ambitious than the first, with the goal of standardizing processes across multiple products in order to realize a single set of customer-aligned processes around the collections and recovery of defaulted loans and credit.

Similar to mortgage lending, collections and recovery was plagued with multiple groups and applications all carrying out similar processes to collect and recover funds for lending products that included credit cards, consumer loans, mortgages, automobile loans, and small business loans. As an SVP of the bank’s CTO Office explained:

“Regardless of the product, collections and recovery is the same: The bank lends a customer something, the customer can’t pay back, and now we have to collect and recover those funds. Even the knowledge and skills of the service providers executing the process doesn’t differ by product.”

As with mortgage lending, the approach was to abstract data and processes from tightly coupled systems. These systems were mostly integrated by point-to-point connections through Java services. The emphasis on reuse became even more pronounced as APIs representing collections and recovery services now joined mortgage services APIs to drive speed and agility.

Developer gains with an application network

As one project developer explained:

“One of the success stories of MuleSoft was being able to read reusable modular services already built on the platform. That is the great thing about the application network. I can now do integration work five times faster.” 

Another developer reported a decline in errors:

“Because there are less moving pieces that are handwritten by developers, there is less need to test the reusable components and therefore less scope for making errors. Once these applications are deployed on Mule, there is probably about 99% less chance of having a bug unless someone really messed it up — all because we’re using reusable components. You don’t have to worry about security either because there are policies that are reusable and applied to APIs as well.”

The gains in developer efficiency are evident in the intersection points between mortgage-lending services and collections and recovery services:

  • Retrieve loan account details API: Any debt collector representing the bank could use this service to look up account details on defaulted mortgages.
  • Search loan documents, documents, and eSignatures APIs: Customer service providers could use this service to reference attributes or documents belonging to specific loans.
  • User experience channels (customer experience APIs): The availability of mortgage-lending and collections and recovery data made it easier to unify the customer experience across all products and lines of businesses.
Collections and recovery consolidation
Illustrative architecture: Collections and recovery consolidation.

My next blog will dive into the bank’s client and customer data platform project. Download our whitepaper, Top 10 global bank drives 5X faster IT project delivery with an application network, for more insight into the bank’s digital journey.



We'd love to hear your opinion on this post