Fintech infrastructure doesn’t have to be terrible
"Fintech" and "regtech" are currently such popular buzzwords that one might assume every bank is implementing modern cloud-hosted systems for every business function at a breakneck pace. The reality is that substantially all of the software used at US banks is still "legacy" software running on-premise. At Alloy, we believe that a transformation is underway in financial software. But for fintech companies looking to sell software to banks, it is critical that they understand how legacy systems work and why they were implemented in the first place. We've spent the last two years creating and integrating regtech/fintech software, dealing with legacy infrastructure, and building new infrastructure for banks. Here's what we've learned.
Why it sucks
To begin taking steps towards fixing financial software, we first have to understand why it became a problem in the first place. The first reason is probably the most obvious: legacy technology is so entrenched in banking processes that it is hard to replace or even update. This is problematic because it assumes that banks or their underlying service providers will never try to innovate or expand to fully online, automated services. We can see that this is not the case by looking at the fastest growing banks and banks with the highest customer satisfaction. For instance, in this 2016 customer satisfaction survey of banks in California, the best banks were by far those with a priority towards innovation and online account opening. BBVA Compass continues to lead in innovation by rebuilding much of its infrastructure and opening it up for fintech developers to use.
We often hear that it is "impossible" to build good fintech software, or use modern technologies to do so, because of oversight and regulation by compliance and security organizations. It is anyone's guess where this notion came from that to be secure and compliant, you must build terrible software, yet it exists. I suppose the assumption is that auditors and regulators have a checklist of technological dealbreakers that hasn't been updated since 1987.
Let's debunk some of the assumptions we've heard in the past:
"You can't build infrastructure in the cloud" — Simple Bank and FINRA themselves both host their infrastructure on AWS
"You can't use open source code in banking software" — most software contains open source material in it. A lot of banking software is built in .NET, which is open source. The key here is to monitor your dependencies and make sure none contain known vulnerabilities.
"Secure software doesn't look pretty" — naturally, if you build a piece of software without security in mind from the beginning, you must continue to glue on makeshift patches in order to shoehorn security onto it. Another easy yet ineffective way to give the appearance of security is to create an obtuse and obscure system. Both of these scenarios result in fundamentally insecure and incoherent systems. The alternative is to build software in a security-conscious manner and treat security requirements just like any other functional specification requirement. More on this idea later.
The last reason bad fintech software gets built is the same reason bad software gets built in any organization — a lack of focus on the end user. In any organization, you have to prioritize making good software or it won't happen. Bad software is built when the process is too distanced from customers, feedback, or a real investment in the success of the end users of the product. This is also why most outsourced software isn't good — and we often see companies who seem to have "in-house outsourced" their development. If your developers don't care about your customers' experience (because they've never met them or don't understand the problem they're trying to solve), they will build software that simply covers the specification. If your developers actually understand the people using their software, they will solve problems the users didn't even know they had.
What we can do about it
The first step towards making consistently good products is to have standards. Below are descriptions of the core standards we've adopted at Alloy that drive our product design decisions. We think they are especially relevant to building good fintech products, but are broad enough that they can apply to any industry. The four qualities that should drive every good piece of software are that it be API driven, transparent, customizable, and consolidated.
A surprising number of processes in financial technology are not data-driven at all. It may be difficult to believe, but most decisions at banks are still made manually, and with little support from software. If you apply for a bank account at most banks, someone in the back office looks at the information you provided, queries a few databases to see if the records match, and then approves your application (usually with at least a couple days turn-around). It's not surprising that banking compliance is a $70 billion industry growing 25% every year considering rising regulatory scrutiny and a lack of automation in these processes. The vast majority of that compliance spend is just on headcount and it is getting worse — in 2016 23% of financial institutions reported a significant increase in employees focused on CDD/KYC.
As more people start banking relationships online instead of in a physical branch (23% in 2015 according to polling by Aite Group), it becomes more important to do as much of the onboarding work in real-time as possible. 13% of businesses reported that they changed banks just due to long onboarding processes and only 11% said they had a "good experience" with onboarding. Customers are beginning to expect online offerings and real-time approval processes, and the fastest growing banks are ones that make that a priority.
The dichotomy at the heart of current financial technology seems to be between transparency and obfuscation. Implicit in the very nature of the software we're building is a necessity to be transparent — audit-ability. The ideal financial software would be completely transparent to companies that are using it as well as auditors who monitor those processes. Almost every data source that Alloy integrates with, from large credit companies to small "cutting edge" identity providers, returns at least one score of unknown and inscrutable origin. What exactly is an address worthiness score of 78/100 supposed to mean? How was this number calculated? Certainly if a company was asked to explain why they either turned away or accepted a customer based on an address worthiness score of 78/100, they would be unable to do so without additional information.
The most important information any financial decision making software can provide is why every decision was made.
We do this as much as possible at Alloy, allowing every customer to have access to every piece of information we used to come to a decision. We also don't cloud any top-level scores we have with "proprietary algorithms" or nebulous machine learning (buzz words often used to cover up inconsistency and inadequacy in design). Machine learning has huge potential in many areas of fintech, but it has no place in something like KYC where the results have to be reproducible and auditable. We collect all the data we get about every identity evaluation and store it encrypted in the cloud, with a direct download link to the audit files sent back by the API. Every aggregated score is a weighted average (where the weights are customizable) or Jaro–Winkler distance (for string matching). In this way, every score can be reproduced by the customer and no numbers are of mysterious origin.
You might not be creating transparent software if:
Your documentation is only available via PDF
Customers can't run a sandbox query until after they have signed a contract
You return any derived data that has unclear origins
You dance around the questions "how does it work?", "where does the data come from?" or "how did you build it?"
Every customer's use case is different, so why should they all have to use the same data sources configured in the same way? Let's look at two examples:
Alice runs a social P2P payments platform. She needs to fulfill KYC/AML obligations (for regulatory purposes), but what she really cares about is social identity verification, in order to foster a community and fight fraud on her platform.
Bob runs a small bank that wants to begin offering online account opening. The bank is under a lot of KYC/AML-related regulatory scrutiny and must make sure all identity information comes from definitive sources like public records or credit headers.
These are two completely different use cases, but both need an identity service. Ideally, Alice would collect enough data to satisfy regulations, as well as some social data and maybe phone network data. Bob, on the other hand, wants to collect data primarily from definitive sources that would satisfy regulators and his compliance department. If both Alice and Bob's companies are using a black-box service, they can't specify (or even tell) where the data comes from or how decisions are computed. What if the "address acceptability score" from the last example was mostly weighted towards social data; is that even useful for Bob? Can he tell if that is the case?
The way we built Alloy allows you to customize every piece of data that we retrieve and compute dynamically. For instance, here is a possible onboarding flow.
Possible onboarding flow: flow runs from left to right, with data sources in green and metadata tags created by the customer in grey.
Each data source, piece of metadata, and threshold is fully customizable. Let's look at one of those links between two data sources.
The "Social Fraud" data source will only be run if certain checks pass based on the response from the "Public Records" data source. No reason to run a social media check if the customer fails a public records lookup!
We believe that all infrastructure should be this customizable because no two customers are the same and no two use cases are the same. With customizability, banks can cover every edge case to make sure they gain the maximum number of good customers possible while also turning away all the bad ones, all in the smallest amount of time and resources.
Customizability helps even after the application is launched and in production. Once applicants begin to get evaluated by the application, why not go back and see if there are any obvious ways to increase conversion or lower friction for future customers? Some companies allow their customers to view statistics about the information they've given via a dashboard, but without customizability to complete the feedback loop, how can this information even be applied? Let's look at a real example of how customizability can help.
If we look at statistics in the Alloy dashboard about how well a specific onboarding application is doing (below), we can see that it is accepting 77.2% of applicants. This is pretty good, but we may believe that we're losing some good customers without a good reason. In this case, it looks like 703 people were denied because we couldn't verify their phone number.
Alloy statistics page showing query metadata
An easy way to rectify this problem would be to add an additional source of data to the onboarding flow that specifically verifies phone numbers, and draws from different data than the existing data sources. This only takes a few clicks and no dev work (all changes can be made in the UI and pushed out to production without affecting the API response structure).
Similarly, if new regulations get introduced, a business can comply with them immediately and with zero developer effort simply by using a more customizable system. If a law went into effect tomorrow saying that all banks must check a new watchlist before onboarding customers, that is as easy as clicking on a new data source. The response structure doesn't change, the additional data is added to new customers' audit archives, and no work is required for developers.
So you have a pretty good product; what's next? The options are usually to develop the product horizontally (try to scale the same product out to different use cases and customers) or to develop vertically (essentially creating an all-in-one product that delights existing customers).
It is easy to make an argument for developing horizontally: more money. When you have a good product that your customers love, you want to stick with it and find other customers in different markets that will love that product. In the case of Alloy, we make an identity product for banks, so why don't we expand what it can do and go after other companies that need online identity verification like Uber or Airbnb? Unfortunately, doing so often aggravates existing customers. Obviously the feature set of the app must expand to accommodate the new customers and how they use it. When done rapidly, this results in feature creep and alienates your current customers by replacing the purpose-built interfaces that they loved with an overcomplicated mess.
Alternatively, you can continue to delight the customers you have by providing a unified platform for all of their needs within the vertical. For Alloy, this meant going from creating identity APIs to supporting that whole universe of actions. We believe that a compliance officer or customer service rep using our software should never have to leave our application to:
help a customer who didn't pass automated screening (correcting incorrect identity info, uploading docs documents, taking notes about a customer, or flagging them for a different department to review)
check archives to remediate a fraud event
provide direct, searchable access to data for a regulator
do statistical analysis on all onboarding data for any subset of customers
generate reports for different business units
When a product delights a set of customers, more will come. Without the feature bloat from developing horizontally, the product continues to delight the old customers and impresses potential ones. Also, you can charge more for those services (helping to alleviate the pain from passing on the horizontal approach).
Having a consolidated system helps your customers at every level of the organization. Customer service reps will love the product because they no longer have to file reports in a different system and solve remediations in word documents while toggling between different identity databases. The C-level executives will love the product because it decreases friction in business processes and customer onboarding.
People think that making good software only benefits the developers who integrate it. Developing with these standards, we can start building software that doesn't just make one developer's life better, but makes a whole industry better.
Since we like to practice what we preach, you can also check out the docs at docs.alloy.co and test the API by sending us sandbox queries — just let us know what you think! :)