Financial Institutions (FIs) are riding the wave of digital transformation to take the advantage of available market opportunities. Fintech companies are rushing to enhance their products and services to embrace the digital transformation using technological advances happened in recent times. The Cards and Payments industry is not an exception. Technology disruptions like Cloud & AI-ML, coupled with API/Microservices led software development, are driving the digital transformation in this practice. Be it an EFT switch application, card & merchant management systems, or payment gateways; major players in the cards and payments space have digital innovation as priority on their company’s roadmap.
In most of the cases, the digital transformation in FIs or Fintech is happening in isolation with applications are being transformed independently. This approach does not address the issue of complex & inflexible systems, overlapping and redundant business functionalities, and inflated maintenance & operational costs. This can be well explained with an example of Customer Profile Management module required in Core Banking as well as Credit Card Systems. If core banking and credit card systems are digitally transformed in isolation, they end up developing their own customer profile management modules. This results in inconsistent, redundant, and overlapping business functionality of customer profile management, and there is a cost involved in maintaining and operating the individual modules in the systems.
So the question comes to mind; can’t there be a single ‘service’ which will offer customer profile management functions and both the applications shall consume the service?
Another challenge which has started surfacing as a by-product of API-led application development is Proprietary Specifications. Many banks and regulators are defining API specifications which are proprietary in nature. For instance, as part of the Open Banking initiative, banks intend to allow third parties/software vendors to access their data via APIs. If each bank defines its own set of Open Banking APIs, it becomes tedious exercise for third parties to integrate with multiple set of API specifications.
To address these issues of overlapping & redundant business functions, as well as proprietary API specifications, there is a need of industry-wide standard of guiding principles, which can be referred by any bank or fintech in a digital transformation exercise.
Fortunately, an already evolving standard is in place to address the needs outlined above. In 2008, many banks and technology providers came together to form a non-profit organization called Banking Industry Architectural Network i.e. BIAN. BIAN’s goal is to define guiding principles to establish an enterprise architecture that the banks across the all geographies can rely on. BIAN covers all banking activities while defining the standard and obviously it addresses the activities of cards and payments practice as well.
To address the needs of standardization, BIAN defines the business functions of any bank as Service Domains and interactions between them as a Service Operations. The service domains and service operations are the building blocks of BIAN framework. The service domains are grouped under business areas and business domains to form a service landscape1. The service landscape can act as a reference model while preparing an Enterprise Architecture of any bank. The BIAN Service Landscape is basically based on principles of ‘Service Oriented Architecture’ (SOA).
In addition, BIAN defines a standard set of RESTful API specifications associated with a service domain. BIAN has setup an API exchange, which can be referred to during application development. They also encourage member contributions to the API exchange, which ensures applications across banks will have uniform API specifications and will make it easier for banks to migrate from one vendor’s product to another. Let us continue with the Customer Profile Management example mentioned above. BIAN defines a service domain called as ‘Party Data Management’. Along with it, BIAN defines various service operations that can be performed on ‘Party Data Management’ and corresponding object models in the form of BIAN Business Object Model (BOM). BIAN’s API exchange offers the specification of various APIs of ‘Party Data Management’ which can be consumed in various business scenarios. Now all the design artifacts of Party Data Management service domain ready, they can be used in various business scenarios of core banking, as well as a credit card system.https://bian.org/servicelandscape-8-0/views/view_27832.html
As mentioned earlier, BIAN covers the cards and payments industry in its service landscape. BIAN working groups have defined service domains, service operations and business object models, which cover business functions of a cards and payment practice. The BIAN API exchange also lists specifications of APIs which can be used in development of card and payment business scenarios.
The software architects working on projects like of Cloud-enablement of EFT Switch or Card Management Systems should analyze how the BIAN framework can be used in the digital transformation. Even though core design principles employed by BIAN have a lot in common with the microservice architecture, the guiding principles can also be applied to technical environments like conventional legacy systems. The “how-to” guides published by BIAN are of great help in the process of applying the BIAN framework. At a high level, the following are aspects that need to be considered while applying the BIAN framework.