A Basic Framework for Banking as a Platform

Over the past few weeks, I’ve met with a few people at various banks, technology companies, and startups that have asked me what’s the value of having an API platform for banks. I like putting things into basic frameworks and I’ve started to develop a basic one for banks, that I figured might be interesting to the few people that read this blog :). As usual, this will be a bit rambly, but hopefully there might be some interesting things that come out…

Currently, banks act as a trusted third party to essentially hold and disburse funds to clients in a traditional hub and spoke model (I’ll admit this is a gross simplification as banks are actually closer to printing money rather simply lend the money that they receive…). However, an API strategy potentially allows banks to create a platform that follows more of a network model, allowing members of a community to come together to create “additional value” or “value-added services”. Just as companies such as Apple, eBay, PayPal, LinkedIn, Facebook, etc connect members within their communities and experience exponential returns with each additional user, banks could do something similar (depending on the use case). Ironically, by shifting to a data-driven platform, banks can start to increasingly look more like banks in the past, brokering new trusted relationships between clients.

In regards to a simple framework, the first obvious differentiation is who is the end user for the data/service being consumed. I then usually split between retail customers (so individual consumers and SMB as they usually fall under the retail side of the house) and wholesale entities (large fortune 500 companies). Next, I split between two basic functionality of the API: the ability to either read or write data. Finally, I break out various uses cases and value props to make it tangible!

Retail

• Read APIs
• Functionality:
• Ability to read data in a user’s bank account — transactions, information, etc (like Plaid!)
• Write APIs
• Functionality:
• Ability to actually transfer funds, open accounts, open services etc. (doesn’t really exist…Seed.co, Fidor, and others are creating their own standalone banks in order to provide these)
• Currently there are third party APIs that allow for the transfer funds in a programmatic manner (aka third party processors such as Stripe, Forte, PayPal, etc)
• Value Prop for a Bank:
• Account aggregation is nothing new, users have been giving away information for years whether that be through screen scraping, PDF files, etc and companies will find ways to extract data to provide new data-driven solutions
• Partnering with a provider that’s able to create a platform that developers actually want to use + an extreme focus on API functionality, servicing, security, etc that allows bank to focus on screening use cases and expose the company to innovative solutions for end-users as a value proposition
• Access to (relatively) real-time data extremely important for SMBs
• Offering ability to open bank accounts in a programmatic (but also federated manner due to KYC/AML requirements) as an expansion strategy — helping to move away from traditional high-cost branch driven expansion; opening more accounts programmatically by a user has almost no marginal cost as compared to branch staff headcount
• Huge internal use case to allow internal developers to easily create new solutions that could potentially compete against new third party services, make errything “agile”
• Banks should use their brand as a secure holding center for money as a value proposition to millennials; a common argument against banking development platforms is about how it doesn’t make any sense to make it easier for users to transfer in and out as the bank wants to maintain the core relationship. The bank that actually allows me to track where my money goes in and out of various services that I use in one centralized location will be the primary bank that I park my money at the end of the day. I still believe that the average millennial (that has disposable income) will still trust a bank to hold the money, although reading media releases makes it seem completely opposite. Most users don’t want to connect multiple bank account to a service, and so will pick the one that acts as their primary bank account; opening up a platform for development would allow a bank to potentially shift funds from competitors to be the primary bank.

Wholesale

• Read APIs
• Functionality:
• Same as above
• Write APIs
• Functionality:
• For simplicity sake, same as above
• Value Prop:
• Offer clients programmatic access to their data, which usually exists in spreadsheets and requires days of work to organize. For large clients that have hundreds of bank accounts at various banks, it can often take days to figure out their total liquidity, a relatively real-time API that allows the client to create their own customized solution would free up internal development resources as well as allow low/medium priority clients to create their own solutions, when traditionally they would have to wait for a bank to (finally) prioritize and build something that they would end up not using. By enabling clients to focus on creating the solutions that they want, frees up the bank to focus on core products and services rather than needing to endlessly prioritize and deliver subpar products
• Much easier said than done, requires a lot of work aggregating various data silos, cleaning, standardizing common identifiers, edge cases, close dates, etc. But all of this is done at some point or the other manually, which inherently means it should be doable programatically…theoretically
• Differentiating factor for traditionally commoditized services such as payments, and (increasingly so) liquidity solutions; revenue opportunity for an “app store”, API usage, etc
• Clients can leverage APIs to create customizable, self-service experiences
• Third parties can focus on creating innovative/novel solutions focused on specific use cases or clients
• Similar internal use case as above!