How Banks Can Embrace Open Banking With Regulatory Compliance

Originally published in . Link.

Cloud computing and other innovations have opened up opportunities for banks to embrace an open banking strategy. To do so, however, banking leaders need to consider how to build up a new ecosystem of services and data that comply with various regulations and adopt a strong security model, such as the TOTAL security model that I recommended in a recent article.

Despite skeptics and challenges with regulatory bodies, the adoption of cloud in various forms—including PaaS, IaaS and SaaS—is redefining the computing ecosystem. Among other regulations of note—from the Federal Financial Institutions Examination Council in the U.S., the European Banking Authority in the EU and the Monetary Authority of Singapore—the latest Canadian OSFI B-13 regulatory requirement on cloud portability invites substantive debate as cloud computing in banking takes center stage and open banking gains traction.

In this article, let’s look at how finance fabric could assist with the engineering enablement capabilities to accelerate the rise of open banking.

Complications Of Banking Cloud

Over the last several years, organizations, including banks, have learned plenty of lessons from their experiences of migrating existing applications, data and other enterprise systems to the cloud.

With the unexpected pandemic, the rise in cyberattacks and increased economic uncertainty, however, institutional changes loom large in the financial sector. Banks must adapt safely and swiftly to mitigate against systemic risks. The cloud in banking, for example, challenges and pushes the boundaries of the core functions and divisions between IT, operations and other lines of business. How do you, for example, provision infrastructure and attach a price tag in terms of development budget versus operational cost?

In solving this challenge, banks often run into fundamental misconceptions about cloud computing. What was perceived as a plug-and-play paradigm drifts into a plug-and-pay nightmare. When adopting a supposed pay-as-you-go, optimized provisioning of infrastructure or computing capacity, banks discover applications, data and machine-learning deployments are locked into the selected cloud platform.

Deeper complications start to surface. One of the promises of the cloud is to create a new enterprise application and data ecosystem that modularizes monolithic systems, such as microservices and automates the testing and releases with DevOps. This is only true with compromises: Cloud-dependent monolithic applications and data systems emerge, which cost far more than expected because what was traditionally under the control of the banks moved to chargeable services provided by the cloud vendor.

These challenges are further complicated by cybersecurity challenges and stability risks due to frequent updates needed with cloud services and products.

Finance Fabric For Cloud Portability

Some banks that leverage the cloud for computing create Agile DevOps computing pipelines for teams to migrate their applications. This is typically called “computing fabric.” Other banks create centralized data lakes and make them accessible via applications on the cloud, otherwise known as “data fabric.”

These are both good approaches to managing data or modernizing applications towards cloud platforms. But, consider a different approach: the STAGE model, which I wrote about recently.

The STAGE model helps create cloud-native microservice applications and federated data lakes targeting hybrid multicloud platforms. This strategically changes the approach. It goes beyond modernizing applications by containerizing and deploying them onto the cloud platform; instead, it enables the bank to embrace an open banking strategy with finance fabric, an architecture framework where banking data and applications live and interact with each other.

How To Move From Monolithic Systems To Open Banking On The Cloud

In the banking world, most technology leaders know about monolithic systems. Many of the legacy applications, data repositories and vendor-installed systems are monolithic systems. Like the elephant in the living room, a monolithic system is hard to live with; it is hard to make it perform. When it moves, as it inevitably will, it is risky. Many of us may have been working with one such monolithic system for a while but still, know very little about it or how to change it to fit into the cloud computing platforms for open banking.

Granted, many banks are rushing to migrate applications, data and analytics onto the cloud, but do they have an exit strategy? Vendors and their cloud technology and tools come and go, but your business must continue. What works now on one cloud platform may need to migrate to another for regulatory, security or business continuation and operational considerations. This is where portability becomes essential, and finance fabric can help.

Let’s look at a five-step roadmap to enable finance fabric.

1. Develop and prioritize strategies for fabrics for data, fabric or service under the umbrella of the STAGE model.
2. Enforce domain-driven design to build a reference and target architecture, develop and socialize governance procedure and implementation policy for security and risk control. Steps 3, 4 and 5 are iterative and incremental, best aligning with regulatory programs.
3. Deliver quick wins to build and validate the prioritized finance fabric components.
4. Deploy microservices, data pipelines or self-service analytics on top of the finance fabric.
5. Scale out to build up the open-banking ecosystem while adding more fabric capabilities.

Finance fabric is an architectural framework with which to build the engineering enablement to implement the strategy of cloud portability, where applications, data and machine learning or AI capabilities are designed, developed and deployed to pertaining patterns. These patterns respect three fundamental architectural principles.

1. Automation is the starting point rather than the afterthought.

2. It should be business-first; in other words, emphasizing domain-driven design rather than giving control or preference to exotic technological features from cloud services or products.

3. Application frameworks must be differentiated from data frameworks and further from frameworks for third-party API interaction, analytics, machine learning and so on. The minimum is to prevent one-size-fits-all solutions.

Finally—and perhaps most importantly—automation pipelines must embrace the TOTAL security model governed by the bank rather than vendors of the cloud services and products or third-party.