Back in 2008, when the Banking Industry Architecture Network (BIAN) launched, containers were – as executive director Hans Tesselaar puts it pithily -- “something you put on a ship” and the notion that its members (banks, tech vendors, service providers) could collaborate to create “a revolutionary banking technology framework that standardises and simplifies the overall banking architecture” seemed, arguably, a little quixotic.
Banks were great hulking, sclerotic things often more inclined to pull up a drawbridge than open an API and BIAN’s models looked – certainly to the untrained eye – like chimera. Better to put money, time, and effort into keeping existing wheels turning rather than reinventing them, many cynics may have thought.
Thirteen years later, BIAN's “bank on a page” models of standardised semantics looks less peculiar and more prescient -- and any organisations on the outskirts of membership that had not recognised the ever growing cost for IT integration/modernisation certainly now have. (Those who simply did not realise the extent to which excessive complexity in application portfolios was crippling their ability to deploy new technologies and business models have also woken up; thanks in large part to cloud experiments of often mixed success.)
Pressure from low interest rates, containers, and customer pressure all make interoperability look ever more sensible...
BIAN was set up out of recognition that IT investment was too often just (expensively) adding more layers of complexity into environments already struggling with interoperability issues.
It proposes a map of service domains: building blocks of discrete business capabilities in a bank. (Its latest iteration of this standardised framework include 308 service domains 2,000+ business scenarios and 2,500+ service definitions.) The idea is to tackle -- by providing an open standard that establishes a utility for the industry -- a climate and environment in which digital transformations are often expensive, trouble-wracked processes. Crudely, using BIAN models and APIs, everyone has the same definition of what X service is and responds to it in the same way.
As Hans Tesselaar tells The Stack the need remains great: “Nine out of 10 banks are still old, established institutions. They are early adopters of automation, but they also have something from every era in IT in their IT landscape, COBOL, C++, Fortran… [Yet] they increasingly need to interact on a broader array of functions and develop new services.”
This underlying vision of a “service domain landscape” that can be configured into an agile bank is alive and kicking, as banks push to meet customer needs for more personalised products with wider features, competitors from the technology realm continue to push into finance, and a low interest rate environment makes the need to develop fee-paying products more important for banks.
Tesselaar points to BIAN member, Shanghai Pudong Development (SPD) Bank which has launched something it calls “panoramic banking”: a BIAN API-led bid to “redefine open banking from the dimensions of customer experience, empowerment, credit enhancement, and value co-creation, innovate business models, expand service boundaries, and reshape service capabilities.” (The verbiage sounds somewhat opaque. The idea isn't: it entails giving customers a lot more services; from informaiton on where the nearest ATM is when they're travelling, through to customised insurance offerings).
BIAN’s members meanwhiel have made more than 22,000 downloads from its 185-API strong open source sandbox, which features open APIs spanning everything from mortgage loans to product matching, system administration, reward points redemption, issued device tracking, asset securitisation and ATM network operations.
The sandbox gives members developing and sharing the APIs all the tools to cross-pollinate a lot more robustly with third-parties in a standardised format, although Tesselaar admits BIAN itself has limited visibility into how the APIs are being used by members.
Does cloud challenge BIAN's mission?
With banks increasingly moving core banking onto the cloud (however slowly or carefully), where bank A and bank B may both be running a range of a given hyperscaler’s services, even from the same region or data centre, does that not begin to imply the likelihood of more cloud-native service-based interoperability?
Tesselaar laughs: “That’s like saying that everyone who drives a Mercedes Benz understands each other.
"What runs on the cloud boxes is still proprietary. Payments may happen from bank A to bank B in an AWS data centre; that doesn’t mean they both have the same semantic definition of a customer.”
Along with the perennial challenge of getting as many members (on paper) to start putting in the work, among BIAN's current focuses is creating a platform for banks to collaborate with leading software vendors on developing a “future-proof, regulatory-compliant and universally compatible banking infrastructure based on BIAN micro-services” that envisions a “coreless bank”. As BIAN put it in late 2019: "The initial focus of the pilot is to develop API-based micro-services covering consumer payments, customer offers and consumer loans. BIAN’s Coreless Banking platform will permit the following functions:
- "Complete plug and play functionality, to ensure no impact to user experience
- "Fully deployable to the cloud, so users can take advantage of modern software development techniques
- "Bank consumable API interface to orchestrate (where necessary) BIAN APIs and reduce network traffic
- "Cross domain orchestration to also reduce network traffic.
In simplest terms this is likely to include a set of standardised microservices that allow banks to invoke services from different vendors.
As Tesselaar puts it in a call with The Stack: “We want to deliver something that is reusable and implementable. Coreless gets them [members] away from vendor lock-in.”
Martin Whybrow of nextgen core banking solutions notes that the first PoC, which took slightly under two months, "involved Infosys, Technisys, Finxact, IBM and Zafin Labs... Using BIAN APIs and microservices, the application vendors focused on providing access via an orchestration layer to their out-of-the-box offerings for simple (create, transact, terminate) processes for current accounts, savings accounts and loans."
Another POC is planned this year. Again, technology vendors feature a lot more heavily than banks themselves, but there are growing examples of multinational banks putting BIANs work to use; witness October 2020's webinar in which the Canadian Imperial Bank of Commerce (CIBC), one of Canada's "big five" banks talked through how it mapped every single application in its domain to a BIAN service domain, allowing it to "identify applications that overlap across multiple service domains and applications that support similar capabilities."
As the bank's Messalina Cadiz-Tostevin put it: "[Using BIAN's models] will assist us to evolve our core banking capabilities into a componentised framework... and adapt to changing market and technology demands."
Change is needed, but despite it being so necessary across the financial services sector, Hans Tesselaar notes: "Banks are robust things. And there's an appetite to really evolve. We've had 6,000 people on our past 10 webinars. People are paying attention."
