This is the third in a series of four posts on the Open Banking Standard (OBS) in the UK. This second post will briefly look at the strategic drivers for banks while proposing an architectural style or approach for incumbents to drive change in their platforms to achieve OBS Compliance. The final post will discuss a reference architecture for the OBS.
The Open Banking Standard will steward the development of layers of guidelines (API interoperability standards, data security & privacy and governance) which primarily deal with data sharing in banking. The belief is that this regulation will ultimately spur open competition and unlock innovation. For years, the industry has grappled with fundamental platform issues that are native to every domain of banking. Some of these include systems are siloe-d by function, platforms that are inflexible in responding to rapidly changing market conditions & consumer tastes. Bank IT is perceived by the business to be glacially slow in responding to their needs.
The Open Banking Standard (OBS) represents a vast opportunity for banking organizations in multiple ways. First off, Bank IT has the luxury of using the regulatory mandate to slowly re-architect hitherto inflexible and siloe-d business systems. Secondly, doing so will enable Banks to significantly monetize their vast data resources in several key business areas.
This will need to change with the introduction of Open Banking Standard. Banks that do not change will not be able to derive and sustain a competitive advantage. PSD2 Compliance (Payment Systems Directive – 2) – which will be mandated by the EU is one of the first layers in the OBS. Further layers will include API standards definitions for business processes (e.g View Account, Transfer Funds, Chargebacks, Dispute Handling etc).
The OBWG (Open Banking Working Group) standards include the following key constituencies & their requirements  –
- Customers: defined as account holders & businesses who agree to sharing their data & any publishers who share open datasets
- Data attribute providers: defined as banks & other financial services providers whose customers produce data as part of daily banking activities
- Third parties: Interested developers, financial services startups aka FinTechs, and any organisations (e.g Retail Merchants) who can leverage the data to provide new views & products
It naturally follows from the above, that the key technical requirements of the framework will include:
- A set of Data elements, API definitions and Security Standards to provide both data security and a set of access restrictions
- A Governance model, a body which will develop & oversee the standards
- Developer resources, which will enable third parties to discover, educate and experiment.
The Four Strategic Drivers in the Open Bank Standard …
Clearly the more intelligently a firm harness technology (in pursuit of OBS compliance goals) will determine it’s overall competitive advantage. This important to note since a range of players across the value chain (the above Third Parties as designated by the standard) can now obtain seamless access to a variety of data. Once obtained the data can help the Third Parties reimagine it in manifold ways. For example they can help consumers make better personal financial decisions for their clients at the expense of the Banks owning the data. For instance, FinTechs have generally been able to make more productive use of client data. They do this by providing clients with intuitive access to cross asset data, tailoring algorithms based on behavioral characteristics and by providing clients with a more engaging and unified experience.
So, the four strategic business goals that OBS compliant architectures need to solve in the long run –
- Digitize The Customer Journey – Bank clients who use services like Uber, Zillow, Amazon etc in their daily lives are now very vocal in demanding a seamless experience across all of their banking ervices using digital channels. The vast majority of Bank applications still lag the innovation cycle, are archaic & are separately managed. The net issue with this is that the client is faced with distinct user experiences ranging from client onboarding to servicing to transaction management. Such applications need to provide anticipatory or predictive capabilities at scale while understand the specific customers lifestyles, financial needs & behavioral preferences.
- Provide Improved Access to Personal Financial Management & Improved Lending Processes – Provide consumers with a single aggregated picture of all their accounts. Also improve lending systems by providing more efficient access to loans by incorporating a large amount of contextual data in the process.
- Automate Back & Mid Office Processes Across Lending, Risk, Compliance & Fraud – The needs to forge a closer banker/client experience is not just driving demand around data silos & streams themselves but also forcing players to move away from paper based models to more of a seamless, digital & highly automated model to rework a ton of existing back & front office processes. These processes range from risk data aggregation, supranational compliance (AML,KYC, CRS & FATCA), financial reporting across a range of global regions & Cyber Security. Can the Data architectures & the IT systems that leverage them be created in such a way that they permit agility while constantly learning & optimizing their behaviors across national regulations, InfoSec & compliance requirements? Can every piece of actionable data be aggregated,secured, transformed and reported on in such a way that it’s quality across the entire lifecycle is guaranteed?
- Tune Existing Business Models Based on Client Tastes and Feedback –While the initial build out of the core architecture may seem to focus on digitizing interactions and exposing data via APIs. What follows fast is strong predictive modeling capabilities working at large scale where systems need to constantly learn and optimize their interactions, responsiveness & services based on client needs & preferences.
System Architecture Requirements for compliance with the Open Bank Standard …
The OBS calls out the following areas of data as being in scope – Customer transaction data, customer reference data, aggregated data and sensitive commercial data. A thorough review of the OBWSG standard leads one to suggest a logical reference architecture as called out below.
Based on all the above, the Open Bank Architecture shall –
- Support an API based model to invoke any business process or data elements based on appropriate security by a third party . E.g client or an advisor or a business partner
- Support the development and deployment of an application that encourages a DevOps based approach
- Support the easy creation of scalable business processes (e.g. client on boarding, KYC, Payment dispute check etc) that natively emit business metrics from the time they’re instantiated to throughout their lifecycle
- Support automated application delivery, configuration management & deployment
- Support a high degree of data agility and data intelligence. The end goal being that that every customer click, discussion & preference shall drive an analytics infused interaction between the Bank and the client
- Support algorithmic capabilities that enable the creation of new services like automated (or Robo) advisors
- Support a very high degree of scale across many numbers of users, interactions & omni-channel transactions while working across global infrastructure
- Shall support deployment across cost efficient platforms like a public or private cloud. In short, the design of the application shall not constrain the available deployment options – which may vary because of cost considerations. The infrastructure options supported shall range from virtual machines to docker based containers – whether running on a public cloud, private cloud or in a hybrid cloud
- Support small, incremental changes to business services & data elements based on changing business requirements
- Support standardization across application stacks, toolsets for development & data technology to a high degree
- Shall support the creation of a user interface that is highly visual and feature rich from a content standpoint when accessed across any device
The design and architecture of a solution as large and complex as a reference architecture for Open Banking is a multidimensional challenge and it will vary at every institution based on their existing investments, vendor products & overall culture. We will discuss a reference architecture in the final post.
 The Open Banking Standard –