Open source is coming to financial services
future.a16z.com
future.a16z.com
Every single one of our customers is looking for a path back to something that looks like the mainframe in terms of vertical integration of the business stack. Most got taken for a really bad ride by legions of consultants over the last ~2 decades and now have to visit 5-10 different system interfaces to take care of a single customer - A horrible combination of green screen, web sites and random pieces of paper that have to be scanned in just right. The list of procedures for some types of activities is bigger than the stack of disclosures the end customer receives.
Many of our clients are stuck in some contorted stance with half their stack in AS400-land and the other half scattered to the various "cloud" services which are mostly just random websites/services with shitty SOAP APIs (or no APIs at all).
The only financial services companies that are seeing positive uplift from these sorts of initiatives are those with enough resources to try this path, fail at it, and then decide they wanted to build 100% of their own stack in-house anyways.
The issue is a lot of the executives that join the bank's C-suite after 10-15 years of experience usually come from consulting... And as you can imagine they keep hiring and re-hiring their old firms to have 2-3 business graduates come and make a PPT telling a room full of engineers and developers how they should be building complex systems.
This is unfortunately not an experience I am unfamiliar with. I have to pretend to eat a big plate of humble pie on the first technical call with a lot of our clients.
Once you learn their first reaction is going to be to reject your proposal on arbitrary grounds (i.e. a new security theater show), you start to present simpler proposals purely for the sake of tripping their initial response. Once you get them to fire their objections across the way, it is really easy to review the impact and build the real proposal that meticulously deals with each point that was raised.
Most of our biggest clients leadership is filled with ex-employees of my firm.
The nuance with M&A between 2 banks is that one usually "wins" in terms of the core tech (i.e. where all the customers and accounts are ultimately stored) and absorbs the other. There are companies that specialize in this exact activity. The part where it gets super messy is with the jurisdiction-specific systems & procedures that have to be folded into 1 operational space.
I find myself considering if I even want to turn my years of experience into a bunch of ML-ops rules for these people in the first place...
This was the most painful lesson we had to learn so far.
The bootstrapping is the hardest piece looking back on the last half-decade. Once you figure out how to make 3 different customers work using the same code pile, you are moving in a good direction. Implementing for 1 customer at a time in a serial fashion is a path for guaranteed failure if you are expecting to just copy that code pile to the next one and have it fit their needs. We tried to do this 3 times and only by the grace and understanding of our angel investor are we still doing business.
My new job is to ask the question "Will this feature/function/enhancement work for all current and future hypothetical clients?". Forcing the team to think in this way was a challenge, but it's kind of our default mindset now. When you guard for bullshit like "what if the account number is longer than 64-bit integers for some future customer?", you trivially-sidestep things that have literally killed other businesses. Clearly, you can take all of this too far, but only if you actually implement in code the proposal before realizing your mistake.
What is this stack? A single, strong, RDBMS and a lang/environment like FoxPro/dBase and equivalents. For reasons, this stack was killed (intentionally?) by their own owners and replaced by a lot of moving parts.
That is why for deploy something you need dozen of things!
---
I think the time is ripped for a return to this kind of stack. I'm betting a little on it at http://tablam.org, if wanna check a small part of the puzzle.
So, while I am sure it can often look like a comedy of errors from the inside, I'm less certain that it is worse than any other sector. Nor would I ascribe such problems on the tired scapegoat of MBAs: plenty of tech people have been promoted to management in the past, and if their results were obviously better, even the most corrupt country club management would have to change their ways at some point.
> Every single one of our customers is looking for a path back to something that looks like the mainframe in terms of vertical integration of the business stack.
I think this is always going to be true as a desire, but it's also true that it's likely an impossible state to achieve completely. There will always be consolidation efforts, but with the rate of M&A and growth of new markets and alternative products, I don't think anyone can afford only consolidation as a strategy today. So in the end, it's a losing battle to try and avoid system sprawl at the moment.
> The only financial services companies that are seeing positive uplift from these sorts of initiatives are those with enough resources to try this path
My view has been the exact opposite, only the resource heavy FS companies are the ones who can afford to pursue consolidation!
> Many of our clients are stuck in some contorted stance with half their stack in AS400-land and the other half scattered to the various "cloud" services which are mostly just random websites/services with shitty SOAP APIs (or no APIs at all).
My take, and what I think this article is poorly commenting on, is that everyone is betting on and trying to pursue open banking. Rather than move internal systems into a more simplified format, pushing the market to use common standards and unify behavior across the industry. We're in a phase that is not quite there yet, but bits and pieces are starting to move, so it's very messy. And that's why it seems that strategies for vertical integration and open-source both can coexist in the zeitgeist today.
Caveat, I do work on tech innovation from a regulator and FMI side, so I'm certainly missing the nitty gritty of your perspective.
For a long time the most important factor was a head count rather than quality. Financial institutions often used loopholes to ship workers from 3rd world countries and indirectly paid them their country of origin wages and small allowances. These workers would live in wholly rented hostels and replaced every 6 months (to avoid residency laws messing the tax implications).
Thank you very much for mentioning the reality of mainframes.
If something needs to work, always, every-time and with minimal maintenance, mainframe it is, that's the good thing,
The bad thing is, that occasionally you have to change your code (external factors) and since it was just running in the past (say >20y), you completely forgot to have a cobol-dev at hand.
On the other side, I appreciate that VCs like a16z are pushing forward these ideas. I don't necessarily think this article is a reflection of the current reality but it does suggest a future. It signals that a16z is looking for startups to invest in to move this space forward.
For those interested in FS and open source today, especially through a capital markets lens check out:
Lots of great projects, one I used recently and a favourite was this:
Perspective was, in a previous life, a proprietary internal engine for Python/desktop applications at JPMC, that was ported and open-sourced to FINOS as a web assembly based browser component. Open sourcing perspective had a huge impact on the project, not just from the awesome community contributions and engagement and support from FINOS itself, but (as a huge surprise to me) the perspective project's visibility within our company.
I think I am in love :-) This is what WebAssembly is supposed to for! Could it easily find the "how to contribute" if there is one please point me at it :-)
I contrast that with the Moov.io repos (full disclosure, I'm familiar with them though I haven't contributed), and they're actually nitty gritty details of dealing with the banking system (at least in the US), things like processing ACH files, wires, ISO 8583 (card network) messages, Image Cash Letter, watchlists needed for KYC and OFAC checks, etc.: https://github.com/moov-io
TBH it just sounds like a very apples-to-oranges comparison.
That said, the major blockers for financial services, at least in my country, are sort of unrelated to open source software being available.
Thinking about the most basic questions one needs to answer to start a fintech:
1. I want to create a bank. How do I do that?
2. I want to issue credit cards / lend money / make a payment system. How do I do that?
3. I want to start an investment fund. How do I do that?
Those are just some examples, but each one of those questions lead to infinite rabbit holes of laws, regulations, bizarre costs and arcane systems to integrate to.
I have more experience with (3) and stuff like getting reliable market data, connecting to brokers and exchanges, sticking with compliance rules, etc... are easily the most painful and costly bits of my job.
It's possible to start a bank, issue cards, facilitate payments, etc. all on pre-built infra + APIs and your job becomes building the user experience and customer/vertical-specific tools on top.
#3 get a copy of excel.
1. How can I prevent someone else from creating a bank.
2. How can I prevent someone else from being able to issue credit cards / lend money / make a payment system.
3. How can I prevent people from being able to make investment funds.
[0] Paywalled, but a relevant link where I pulled those company names from. https://www.americanbanker.com/news/why-more-banks-are-ditch...
Many public/commercial APIs/feeds have SDKs available by the provider and even when not most of the the work involved goes in getting the data/messages to and from the banks system/data format/language.
Most code for things like entity matching, fraud detection is highly tied to the data the bank has which often - due to the various other banks the bank has purchased and has partnerships with - may be a huge mass of data. An open source library would probably help with 5% of the work. Great if its being pushed by consultancy that can do the glue work for a fee.
In the area where I've mostly worked in - the trading side of investment banking, the computing systems - trade handling, pricing is seen as a competitive advantage, that you don't share with competitors. I made some fixes to a low level communication/transaction library for a vendor library we used (giving them the code meant we wouldn't have to patch it every release) that took nearly 9 months to get approval.
I could see Banking services as a Service would be more appealing to the banks i've been in.
In asset and also in wealth management but to a lesser degree it is a total disaster zone. Technical debt is being hidden to keep shareholders happy but it is not sustainable. Open source is not being used - at least not in the areas of systems we come in to contact with at Fundipedia.
1. There are lots of Banking as a Service platforms for fintechs that want to essentially be the end-user facing platform, but then funds are held at a chartered, FDIC-insured bank. Companies like Q2 and Treasury Prime.
2. There are then a slew of companies for things like Card Issuing as a Service, KYC as a Service, Fraud Monitoring as a Service. Companies like Stripe, Marqeta and Lithic on the card issuing side; Alloy, Socure, Unit21 on the KYC side; Sift on the fraud monitoring side, etc.
This post is basically arguing about open source companies providing "lower level primitives" in the form of libraries that people can build on top of, i.e. libraries for creating and processing ACH files, sending and receiving wire transfers, financial ledgers, syncing for required OFAC checks, etc. Building these things from scratch today is extremely difficult, not just because it takes time, but because (at least to me), it feels like so much stuff in the financial industry is poorly documented, or perhaps its better to say that the documentation is only half the story - what is required in practice and by what regulators really care about just takes "tribal knowledge" from banking experience.
Not saying one way or the other whether I think the author's thesis is correct, but I think it's a good topic for discussion, and is orthogonal to things like Open Banking APIs.
Said another way, let's assume the regulator is not keeping up on the latest and greatest trends. Let's also assume the regulator wants to avoid adding lots of extra work and due diligence. We could assume the regulators were not quite as smart as the higher paid banking executives. What do you think the response will be when you push for big changes that need to happen quickly? What incentives exist for regulators to change?
This is not true at all. Regulations that span multiple countries like the EU's MIFID I (2007) have been around for a long time. Even institutions in countries outside these markets would need to comply when they want to participate in the market. One of the companies I worked for previously has been licensing financial software (including those implementing national and international regulations) for decades to financial institutions across world, and they were not alone in their market. Going global is nothing new in this industry. Neither is open source. QuickFIX, for example, is two decades old.
Here they’re talking about the Wild West of small banks that they have.
Literally how many startups spawn in America for simple financial tasks that are easily handled by banks in the UKEU? In some cases, there are banks in India and most of the developing world that have more advanced services for consumer banking than the US. China has obviously already raced ahead far more than the US.
In Europe, for example, there's 6,000 banks and there's at least thousand different interpretations of what is a PSD2-compliant API, which makes connectivity hard - you have to use an API aggregator to connect to all these APIs (unless you want to connect to each API separately). If they all just used open source libraries, we'd have less APIs to connect to, which means better connectivity.
Ive been building one myself but i know there are many more coming for this industry :)
The only way an organization can revamp this is by actually owning the technology entirely in-house and building up a completely independent product and engineering division.
At the end of the day, changing code is orders of magnitude cheaper than a change management project with 12 managers and mandated retraining of 400 internal personnel.
In my humble opinion, this type of change in the financial services industry can not come from incumbents.
AWS heavy open source base: https://aws.amazon.com/financial-services/ Gcp, same story: https://cloud.google.com/solutions/financial-services
Coming soon to a USPS near you. It'll be like 1965 again.
Also, lots of neobanks are offering free accounts and features because their revenue comes from interchange on spending + interest + future cross-sells or lending.
If you answer is: To be able to make payments
Then maybe a better question is -- Why should people need bank accounts to make payments.
Note: Banks are not likely to ask this question
Many retirees would fall well into the "people without money" category, but they still need to get their Social Security payment direct deposited.
Many employers, especially in low-wage "people without money" sectors, aggressively push extortionate-fee prepaid-debit products on their workers if they can't accept a conventional direct deposit.
Putting everyone on a single network, at the very least for this use case, reduces cost and complexity. Can you imagine the guaranteed confusion and error in a system where 40% of your employer's payroll was paid over ACH, 25% via crypto transfers split among a dozen blockchains, and the rest via paper cheques or prepaid debit cards mailed out?
Yes, it's not the only possible solution to a payments ecosystem, but it's the closest thing to a universal one we have. People understand how it works and there are well-established risk and mitigation models for it.
This is part of the reason I'm a bit hesitant about things like the "self banking" paradigm via cryptocurrency. Even once we solve the nuts-and-bolts problems of risk mitigation and seamless user experiences, it's likely to be a sharded market for the short term. I can easily imagine incurring fees and delays because my money is in a Dogecoin wallet but the water company only wants Monero to settle their bill.
Develop the code in-house, and it will be guaranteed open source for!
It's coming. Already being tested in Baltimore, The Bronx and a few other places.
Historically, trying to avoid political battles by making services poor-only (whether means testing or otherwise) has been loosing strategy as the Republicans let it through (battle win!) but the service becomes shitty and paternalistic without a strong broad electoral mandate.
The key is making something just about everyone will want to use, letting people vote with their feat, and then it becomes untouchable.
We need the accounts to make UBI stick, but perhaps we should think about it the other way too. Next crises, don't bother with people's existing accounts and instead say "there's a check waiting for you with your already-existing PO account".
Just like Facebook getting people to make shadow account for their friends and spamming you to claim in the olden days!
The whole XaaS picture thing looks like a nice OSI stack type of thing, but it's not how the systems work together (funnily enough networks don't work that way either lol). They're more like a graph, maybe a bowl of spaghetti. For instance the compliance part reaches into everywhere. You can't just write an API layer and do .complies() -> bool. Some of it even requires you to implement PTP timestamps. And it certainly reaches into reporting, where you have all sorts of strange requirements. I recently looked at a file with over 100 columns to be populated.
Having said that there's plenty of use of OSS. I've rarely been anywhere that doesn't use Linux or git or various other common software. I haven't seen a lot of proprietary languages either (Delphi/Slang/Matlab).
More then 95% of operating-systems-kernels are build with C a 49 year-old programming language.
I really can't hear that stupid sentence anymore.
One of the things I'm most concerned about is how credit card payment processors and banks basically define what you can easily buy online. Something can be perfectly legal, but if there's no way to pay for it, it won't be available.
Good analogy. This stuff doesn't apply to 99% of us.