“Banking as a service has long sat at the heart of our economy. In our digitally enabled world, the need to seamlessly and efficiently connect different economic agents who are buying and selling goods and services, is critical. The Open Banking Standard is a framework for making banking data work better: for customers; for businesses and; for the economy as a whole.” – OBWG (Open Bank Working Group) co-chair and Barclays executive Matt Hammerstein
Introducing Open Banking Standards…
On a global basis, both the Financial Services and the Insurance industry are facing an unprecedented amount of change driven by factors like changing client preferences and the emergence of new technology—the Internet, mobility, social media, etc. These changes are immensely profound, especially with the arrival of the “FinTechs”—technology-driven applications that are upending long-standing business models across all sectors from retail banking to wealth management & capital markets. Complement this with members of a major new segment, Millennials. They are increasingly use mobile devices, demanding more contextual services and expecting a seamless unified banking experience—something akin to what they experience on web properties like Facebook, Amazon, Uber, Google or Yahoo, etc. These web scale startups are doing so by expanding their wallet share of client revenues by offering contextual products tailored to individual client profiles. Their savvy use of segmentation data and predictive analytics enables the delivery of bundles of tailored products across multiple delivery channels (web, mobile, call center banking, point of sale, ATM/kiosk etc.).
Supra national authorities and national government in Europe have taken note of the need for erstwhile protected industries like Banking to stay competitive in this brave new world.
With the passage of the second revision of the ground breaking Directive on Payment Services Directive (PSD-2), the European Parliament has adopted the legal foundation of the creation of a EU-wide single payments area (SEPA). While the goal of the PSD is to establish a set of modern, digital industry rules for all payment services in the European Union; it has significant ramifications for the financial services industry as it will surely current business models & foster new areas of competition. While the PSD-2 has gotten the lions share of press interest, the UK government has quietly been working on an initiative to create a standard around allowing Banking organizations to share their customer & transactional data with certified third parties via an open API. The outgoing PM David Cameron’s government had in fact outlined these plans in the 2015 national budget.
The EU and the UK governments have recognized that in order for Europe to move into the vision of one Digital Market – the current system of banking calls for change. And they foresee this change will be driven by digital technology. This shakeup will happen via the increased competition that will result as various financial services are unbundled by innovative developers. To that end, by 2019 – all banks should make customer data – their true crown jewels – openly accessible via an open standards based API.
The Open Bank Working Standard Report API…
Under the Open Banking Standard – expected to be legal reality over the next 2-3 years, any banking customer or authorized 3rd party provider can leverage APIs to gain access to their data and transactions across a whole range of areas ranging from Retail Banking to Business Banking to Commercial Banking.
Open Standards can actually help banks by helping them source data from external providers. For instance, the Customer Journey problem has been an age old issue in banking which has gotten exponentially more complicated over the last five years as the staggering rise of mobile technology and the Internet of Things (IoT) have vastly increased the number of enterprise touch points that customers are exposed to in terms of being able to discover & purchase new products/services. In an OmniChannel world, an increasing number of transactions are being conducted online. In verticals like Retail and Banking, the number of online transactions approaches an average of 40%. Adding to the problem, more and more consumers are posting product reviews and feedback online. Banks thus need to react in realtime to piece together the source of consumer dissatisfaction. Open Standards will help increase the ability of banks to pull in data from external sources to enrich their limited view of customers.
The Implications of Open Bank Standard…
The five implications of Open Bank Project –
- Banks will be focused on building platforms that can drive ecosystems of applications around them. Banks have thus far been largely focused on delivering commodity financial services using well understood distribution strategies. Most global banks have armies of software developers but their productivity around delivering innovation has been close to zero. Open APIs will primarily force more thinking around how banking products are delivered to the end consumer. The standards for this initiative are primarily open source in origin, though they’re widely accepted across the globe – REST,OAuth etc.
- However it is not a zero sum game, Banks can themselves benefit by building business models around monetizing their data assets as their distribution channels will go global & costs will change around Open Bank. To that end existing Digital efforts should be brought in line with Open Bank Standard The best retail banks will not only seek to learn from, but sometimes partner with, emerging fintech players to integrate new digital solutions and deliver exceptional customer experience. To cooperate and take advantage of fintechs, banks will require new partnering capabilities. To heighten their understanding of customers’ needs and to deliver products and services that customers truly value, banks will need new capabilities in data management and analytics. Using Open Bank APIs, developers across the world can create applications that offer new services (in conjunction with retailers, for example), aggregate financial information or even help in financial planning. Banks will have interesting choices to make between acting as Data Producer or Consumer or Aggregator or even a Distributor based on specific business situations.
- Regulators will also benefit substantially by using Partner APIs to both access real time reports & share data across a range of areas. The lack of realtime data access across a range of risk, compliance and cyber areas has been a long standing problem that can be solved by an open standards based API framework . E.g. Market/Credit/Basel Risk Based Reporting, AML watch list data and Trade Surveillance etc.
- Data Architectures are key to Open Bank Standard – Currently most industry players are woeful at putting together a comprehensive Single View of their Customers (SVC). Due to operational data silos, each department possess a siloe-d & limited view of the customer across multiple channels. These views are typically inconsistent, lack synchronization with other departments & miss a high amount of potential cross-sell and up-sell opportunities. Data lakes and realtime data processing techniques will be critical to meeting this immense regulatory requirement.
- Despite the promise, large gaps still remain in the Open Bank Project. Critical areas like project governance, Service Level Agreements (SLA) for API users in terms of uptime, quality of service are still left unaddressed.
Open Banking Standard will spur immense changes..
Prior to the Open Banking Standard, Banks recognize the need to move to a predominantly online model by providing consumers with highly interactive, engaging and contextual experiences that span multiple channels—branch banking, eBanking, POS, ATM, etc. Business goals are engagement & increasing profitability per customer for both micro and macro customer populations with the ultimate goal of increasing customer lifetime value (CLV). The Open Banking Standard brings technology approaches to the fore in terms of calling it out as a strategic differentiator. Banks need to move to a fresh business, data and process approach as a way of staying competitive and relevant. Done right, Open Bank Standards will help the leaders cement their market position.
 The Open Banking Standard –
Big Data – Banking’s New Weapon Against Financial Crime – http://www.vamsitalkstech.com/?p=806
THE STATE OF GLOBAL FINANCIAL SERVICES IT ARCHITECTURE…
This blog has time & again discussed how Global, Domestic and Regional banks need to be innovative with their IT platform to constantly evolve their product offerings & services. This is imperative due to various business realities – the increased competition by way of the FinTechs, web scale players delivering exciting services & sharply increasing regulatory compliance pressures. However, systems and software architecture has been a huge issue at nearly every large bank across the globe.
Regulation is also afoot in parts of the globe which will give non traditional banks access to hitherto locked customer data. E.g PSD-2 in the European Union. Further, banking licenses have been more easily granted to non-banks which are primarily technology pioneers. e.g. Such as a Paypal, Square etc
In 2016, Banks are waking up to the fact that IT Architecture is a critical strategic differentiator. Players that have agile & efficient architecture platforms and practices can not only add new service offerings but also are able to experiment across a range of analytic led offerings that create & support multi-channel products. These digital services and usecases can now be found abundantly areas ranging from Retail Banking, Capital Markets. FinTechs have innovated in areas such as Payments & Wealth Management.
So, How did we get here…
The Financial Services IT landscape – no matter the segment – one picks across the spectrum – Capital Markets, Retail & Consumer Banking, Payment Networks & Cards, Asset Management etc are all largely predicated on a few legacy technology anti-patterns. These anti-patterns have evolved over the years from a systems architecture, data architecture & middleware standpoint.
These have resulted in a mishmash of organically developed & shrink wrapped systems that do everything from running critical Core Banking Applications to Trade Lifecycle to Securities Settlement to Financial Reporting etc. Each of these systems operates in an application, workflow, data silo with it’s own view of the enterprise. These are all kept in sync largely via data replication & stove piped process integration.
If this sounds too abstract, let us take an example & a rather topical one at that. One of the most critical back office functions every financial services organization needs to perform is Risk Data Aggregation & Regulatory Reporting (RDARR). This spans areas from Credit Risk, Market Risk, Operational Risk , Basel III, Solvency II etc..the list goes on.
The basic idea in any risk calculation is to gather a whole range of quality data in one place and to run computations to generate risk measures for reporting.
So, how are various risk measures calculated currently?
Current Risk Architectures are based on traditional relational databases (RDBMS) architectures with 10’s of feeds from Core Banking Systems, Loan Data, Book Of Record Transaction Systems (BORTS) like Trade & Position Data (e.g. Equities, Fixed Income, Forex, Commodities, Options etc), Wire Data, Payment Data, Transaction Data etc.
These data feeds are then tactically placed in memory caches or in enterprise data warehouses (EDW). Once relevant data has been extracted, it is transformed using a series of batch jobs. These jobs which then prepare the data for Calculator Frameworks to which run their risk models across hundreds of scenarios.
All of the above need access to large amounts of data at the individual transaction Level. The Corporate Finance function within the Bank then makes end of day adjustments to reconcile all of this data up and these adjustments need to be cascaded back to the source systems down to the individual transaction or classes of transaction levels.
These applications are then typically deployed on clusters of bare metal servers that are not particularly suited to portability, automated provisioning, patching & management. In short, nothing that can automatically be moved over at a moment’s notice. These applications also work on legacy proprietary technology platforms that do not lend themselves to flexible & a DevOps style of development.
Finally, there is always need for statistical frameworks to make adjustments to customer transactions that somehow need to get reflected back in the source systems. All of these frameworks need to have access to and an ability to work with terabtyes (TBs) of data.
Each of above mentioned risk work streams has corresponding data sets, schemas & event flows that they need to work across. They also have different temporal needs for reporting. Some need to be run a few times in a day (e.g. Traded Credit Risk), some daily (e.g. Market Risk) and some end of the week (e.g Enterprise Credit Risk)
Illustration – The Five Deadly Sins of Financial IT Architectures
Let us examine why this is in the context of these anti-patterns as proposed below –
THE FIVE DEADLY SINS…
The key challenges with current architectures –
- Utter, total and complete lack of centralized Data leading to repeated data duplication – In the typical Risk Data Aggregation application – a massive degree of Data is duplicated from system to system leading to multiple inconsistencies at the summary as well as transaction levels. Because different groups perform different risk reporting functions (e.g Credit and Market Risk) – the feeds, the ingestion, the calculators end up being duplicated as well. A huge mess, any way one looks at it.
- Analytic applications which are not designed for throughput – Traditional Risk algorithms cannot scale with this explosion of data as well as the heterogeneity inherent in reporting across multiple kinds of risks. E.g Certain kinds of Credit Risk need access to around 200 days of historical data where one is looking at the probability of the counter-party defaulting & to obtain a statistical measure of the same. These models are highly computationally intensive and can run for days if the data architecture cannot scale in providing efficient compute on massive volumes of data.
- Lack of Application Blueprint, Analytic Model & Data Standardization – There is nothing that is either SOA or microservices-like in most RDA applications and that precludes best practice development & deployment. All of this only leads to maintenance headaches. The reason that Cloud Computing based frameworks such a a PaaS (Platform as a Service) are highly elegant are that they enforce standardization of systems software components across the stack. Areas like Risk Model and Analytic development needs to be standardized to reflect realities post BCBS 239 (and the upcoming FRTB). With the Volcker Rule reporting that bans prop trading activity on part of the Banks, they must now report on seven key metrics across 10s of different data feeds across PB’s of data. Most existing Risk applications cannot do that without undertaking a large development and change management headache.
- Lack of Scalability – It must be possible to operate it as a central system that can scale to carry the full load of the organization and operate with hundreds of applications built by disparate teams all plugged into the same central nervous system.One other factor to consider is the role of cloud computing in customer retention efforts. The analytical computational power required to understand insights from gigantic data sets is costly to maintain on an individual basis. The traditional owned data center will probably not disappear, but banks need to be able to leverage the power of the cloud to perform big data analysis in a cost-effective manner.
- A Lack of Deployment Flexibility – The application & data requirements dictate the deployment platforms. This massive anti pattern leads to silos and legacy OS’s that can not easily be moved to Containers like Docker & instantiated by a modular Cloud OS like OpenStack.
THE BUSINESS VALUE DRIVERS OF EFFICIENT ARCHITECTURES …
Doing IT Architecture right and in a responsive manner to the business results in critical value drivers that that are met & exceeded this transformation are –
- Effective Compliance with increased Regulatory Risk mandates ranging from Basel – III, FTRB, Liquidity Risk – which demand flexibility of all the different traditional IT tiers.
- An ability to detect and deter fraud – Anti Money Laundering (AML) and Retail/Payment Card Fraud etc
- Fendoff competition from the FinTechs
- Exist & evolve in a multichannel world dominated by the millennial generation
- Reduced costs to satisfy pressure on the Cost to Income Ratio (CIR)
- The ability to open up data & services that operate on the customer data to other institutions
A uniform architecture that works across of all these various types would seem a commonsense requirement. However, this is a major problem for most banks. Forward looking approaches that draw heavily from microservices based application development, Big Data enabled data & processing layers, the adoption of Message Oriented Middleware (MOM) & a cloud native approach to developing applications (PaaS) & deployment (IaaS) are the solution to the vexing problem of inflexible IT.
The question is if banks can change before they see a perceptible drop in revenues over the years?
THE AML CHALLENGE CONTINUES UNABATED…
As this blog has repeatedly catalogued over the last year here, here and here, Money Laundering is a massive global headache and one of the biggest crimes against humanity. Not a month goes by when we do not hear of billions of dollars in ill gotten funds being stolen from developing economies via corruption as well as from proceeds of nefarious whether it is the Panama papers or banks unwittingly helping drug cartels launder money.
I have seen annual estimates of global money laundering flows ranging anywhere from $ 1 trillion to 2 trillion – almost 5% of global GDP. Almost all of this is laundered via Retail & Merchant Banks, Payment Networks, Securities & Futures firms, Casino Services & Clubs etc – which explains why annual AML related fines on Banking organizations run into the billions and are increasing every year. However, the number of SARs (Suspicious Activity Reports) filed by banking institutions are much higher as a category as compared to the numbers filed by these other businesses.
The definition of Financial Crimes is fairly broad & encompasses a large area of definition – the traditional money laundering activity, financial fraud like identity theft/check fraud/wire fraud, terrorist activity, tax evasion, securities market manipulation, insider trading and other kinds of securities fraud. Financial institutions across the spectrum of the market now need to comply with the regulatory mandate at both the global as well as the local market level.
What makes AML such a hard subject for Global Banks which should be innovating quite easily?
The issues which bedevil smooth AML programs include –
- the complex nature of banking across retail, commercial, wealth management & capital markets; global banks now derive around 40% of revenue from non traditional markets (North America & Western Europe)
- the scale of customer activity ranging from 5 to 50 million at the large global banks
- patchwork of local regulations, risk and compliance reporting requirements. E.g. Stringent compliance requirements in the US & UK but softer requirements elsewhere
- tens of distribution channels
- growing volumes of transactions causing requirements for complex analytics
- the need to constantly integrate 3rd party information of lists of politically exposed persons of interest (PEPs) using manual means
- technology while ensuring the availability of banking services to millions of underserved populations – also makes it easy for the launderers to conduct & mask their activities
The challenges are hard but the costs of non-compliance are severe. Banks have been fined billions of dollars, compliance officers face potential liability & institutional reputation takes a massive hit. Supra national authorities like the United Nations (UN) and the European Union (EU) can also impose sanctions when they perceive that AML violations threaten human rights & the rule of law.
TECHNOLOGY IS THE ANSWER…
Many Banks have already put in rules, policies & procedures to detect AML violations and have also invested in substantial teams staffed by money laundering risk officers (MLRO) & headed by compliance officers. These rules to detect money laundering work based on thresholds and patterns that breached such criteria. The issue with this is that the money launderers themselves are in the class of statisticians and they constantly devise new rules to hide their tracks.
The various elements that make up the risk to banks and financial institutions and the technology they use to detect these can be broken down into five main areas & work streams as shown below.
Illustration: The Five Workstreams of AML programs
- Customer Due Diligence – this involves gathering information from the client as well as on-boarding data from external sources to verify these details and to establish a proper KYC (Know Your Customer) program.
- Entity Analysis – identifying relationships between institutional clients as well as retail clients to understand the true social graph. Bank compliance officers now have gone beyond KYC (Know Your Customer) to know their customer’s customer, or KYCC.
- Downstream Analytics – detecting advanced patterns of behavior among clients & the inter-web of transactions with a view to detecting hidden patterns of money laundering. This also involves assessing client risk during specific points in the banking lifecycle, such as account opening, transactions above a certain monetary value. These data points could signal potentially illegitimate activity based on any number of features associated with such transactions. Any transaction could also lead to the filing of a suspicious activity report (SAR)
- Ongoing Monitoring – Help aggregate such customer transactions across multiple geographies for pattern detection and reporting purposes. This involves creating a corporate taxonomy of rules that capture a natural language description of the conditions, patterns denoting various types of financial crimes – terrorist financing, mafia laundering, drug trafficking, identity theft etc.
- SAR Investigation Lifecycle – These rules trigger downstream workflows to allow human investigation on such transactions
QUANTIFIABLE BENEFITS FROM DOING IT WELL…
Financial institutions that leverage new Age technology (Big Data, Predictive Analytics, Workflow) in these five areas will be able to effectively analyze financial data and deter potential money launderers before they are able to proceed, providing the institution with protection in the form of full compliance with the regulations.
The business benefits include –
- Detect AML violations on a proactive basis thus reducing the probability of massive fines
- Save on staffing expenses for Customer Due Diligence (CDD)
- Increase accurate production of suspicious activity reports (SAR)
- Decrease the percent of corporate customers with AML-related account closures in the past year by customer risk level and reason – thus reducing loss of revenue
- Decrease the overall KYC profile backlog across geographies
- Help create Customer 360 views that can help accelerate CLV (Customer Lifetime Value) as well as Customer Segmentation from a cross-sell/up-sell perspective
Virtually every leading banking institution, securities firm, payment provider understands that they need to enhance their AML capabilities by a few notches and also need to constantly evolve them as fraud itself morphs.
The question is can they form a true picture of their clients (both retail and institutional) on a real time basis, monitor every banking interaction while understanding it’s true context when merged with historical data, detect unusual behavior. Further creating systems that learn from these patterns truly helps minimize money laundering.
The next and final post in this two part series will examine how Big Data & Analytics help with each of the work streams discussed above.
 Building AML Regulatory Platforms for the Big Data Era – http://www.vamsitalkstech.com/?p=5
Big Data – Banking’s New Weapon Against Financial Crime – http://www.vamsitalkstech.com/?p=806
 Reference Architecture for AML
 WSJ – Know Your Customer’s Customer is the New Norm – http://blogs.wsj.com/riskandcompliance/2014/10/02/the-morning-risk-report-know-your-customers-customer-is-new-norm/