As someone who develops software products for the financial services sector, I can assure you that the thing most stakeholders are looking for right now is simplification of operations, not sharding operations out to even more vendors (OSS or otherwise).
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 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.
> 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.
This is usually good advice for any time you're selling a proposal. Your first attempt is going to be shot down. The more detail it has, the more ammunition there is to shoot it down. So build the minimum viable presentation that's going to trigger an emotional response and tease out the actual issues. Build the real proposal once you've triggered your customer into revealing what's actually on their mind.
When building a proposal to C-suite or stakeholders bring it to a level they will understand. Don't focus on technology, stacks, interfaces. Focus on efficiency, improved operations, reduced costs, bigger bottom line. This is the language that is hard to argue.
This is my experience as well. I work for a pretty large consultancy and the majority of my projects, when i look up the primary stake holder on the client side that brought us in, oh would you look at that he used to work at my consultancy 3 years ago.
Most of our biggest clients leadership is filled with ex-employees of my firm.
My observation is that everyone is looking to simplify and streamline operations, and the financial sector just suffers more from faults in the pipeline due to every entity being a special snowflake. That said, a proper foundation for these things really isnt that unique to finance imho, once you get past a few of the outliers. My problem is this: you can know how to do this, but the largest hurdle is the army of incompetent middle managers who filter any truth from technically out of date c-suites. No amount of "tech stack" can fix these human problems.
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...
> No amount of "tech stack" can fix these human problems.
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.
I wonder how startups are able to do this with 3 enterprise customers. The amount it takes to get us through procurement has almost already killed a startup I’m working with. Any advice on picking the right customers? We also don’t have that many resources to potentially dedicate to serve 3 enterprises at a time.
I think we're in the middle of a bit of a transition phase within the industry.
> 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.
yep, a lot of this is fallout from the financial crisis and all of the bank mergers that have happened. A number of the big banks i worked with a few years ago had sooo many different systems from all their acquisitions and what they really want is one
This is an excellent point. It's fun to blame consultants, but the amount of M&A that has occurred can probably be implicated for half of the complexity seen in banking today.
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 relate to this. Is not just a lot of vendors, is that the kind of software stack that is optimal for MOST enterprises/companies get out of fashion in the dev community and is replaced with a lot of moving gears. This is how many devs think JS/html are good for UIs or NoSql + micro-services are ok.
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.
I can't recall any major security lapses with online banking, which would seem to be fairly exceptional for a segment of the economy of its size. And, as far as I can tell, there is some pretty impressive technology being used in market operations (both secure & incredibly fast) as well as trading.
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
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.
> bad ride by legions of consultants over the last ~2 decades
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).
I don't like to be too negative, but this article feels like a senior partner or committee brainstormed article topics and assigned it to someone else. It's almost like someone started with an outline of the headers of each article section and the contents were filled in with the most obvious possible content. It feels like the kind of topic/article that GPT-4 or later will pump out en masse in the not too distant future. It's as if someone at a16z said "we need more blog content and we want an article on open source finance" and this was the result.
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.
I work on perspective, glad you dig it! We just released 1.0 this week after 4+ years of open-source-first development.
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 went to the finos website and looked at their list of repositories, and literally none of them looked like things I'd be interested in from a financial services/banking perspective. I saw a lot of very "high level infrastructure" repos for things like processing JSON, standardizing models, etc. The example you gave, Perspective, honestly looks like the most interesting of the ones I saw, but it's still a generic data visualization component.
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.
Cool stuff, most banks, brokers and hedge funds have no FOSS culture.
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.
For 1 & 2, most companies are going to partner with a core banking service provider. Core banking is basically a specialized ERP for banks. The big players are Fiserv, FIS, Finastra and Jack Henry[0]
In the USA, there are XaaS solutions for most of these now.
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.
Worked in Financial Services for a couple of decades and I don't buy this it sounds like a sales talk from a consultancy company. Banks do use (and sometimes contribute) to Open Source libraries - but usually non financial lower level technical things - Apache Commons, front end libraries, FinLib, Messaging systems etc.
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.
If you are referring to retail banking I totally agree.
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.
I feel like a lot of comments are missing the point of this blog post. In the past 5 years or so, there has been an explosion of "XaaS" API companies that many of the new fintechs or "challenger banks" build on top of. For example:
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.
You could argue that it is not the technology stack that creates a barrier to entry for financial services but rather the existing relationships and levels of comfort with the regulators.
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?
> While fintech has traditionally been default local — most banks are driven by country-specific regulations, infrastructure, and consumer payment preferences — many global companies are now adding financial services.
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.
That was precisely my thought when reading this article.
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.
Actually, the article uses "open banking" correctly in this case. The author believes that if all banks used open sourced tools for exposing their data via APIs (as opposed to building everything from scratch), we'd have more connectivity - which is true.
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.
This has also been my opinion for the accounting industry. Just like c compilers before gcc were proprietary and poor performing the accounting software that exists has many limitations. That means there is a huge opportunity for an open source system to blow them out of the water.
Ive been building one myself but i know there are many more coming for this industry :)
I’m looking for bank import tools (ala Plaid) for customers, and it occurs to me that it is absolutely ridiculous in this day and age that there is no universal API for securely delegating read only access to bank transactions. My personal banks managed to finally work with Mint, but even then, some will break if two factor authentication is enabled. This should be a standard.
It's always helpful to make the distinction between problems and solutions; it's true that traditional finance providers are horribly stuck in legacy systems, however their main problem is not so much that they are unable to rebuild. Their main problem is that decision power is so federated across the organization that it's impossible to even decide to rebuild their stack in a vertically-integrated way.
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.
Yeah this sort of feels like one half of an advert campaign. The 'build a need' part. Then a bit later we will get to see who is selling something that just happens to fix it. The links you gave are more for 'banks like to keep their stuff in house but we can keep it secure if you rent our machines'.
This is just fluff. Financial services and banks are not the same thing. The biggest problem with banks in the US is no free accounts, we need banks with physical branches to offer accounts for poor people to have. There is no money in this so a16z would not be interested. Everyone else is looked after already.
As much as anything, people need bank accounts to receive payments to be part of a modern economy.
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.
Also, lots of neobanks are offering free accounts and features because their revenue comes from interchange on spending + interest + future cross-sells or lending.
Odd that this post omits any mention of FinOS, a pretty significant stakeholder in open source and financial services. I wonder why they missed that out?
I am stoked, but it will be a fraught process. Right now it's being rolled out as "a payday loan alternative"---i.e, it's for poor people.
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!
Hedge fund guy in me thinks this is all marketing.
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).
A16 should remember that they also provide financial services and this same thing is coming for them too and might come for them more quickly than traditional banks.
What is the agenda pushing here? This is clearly not a push for change in the actual financial services or banking sector. Is there an attempt to shift power away from "traditional" banks to "untraditional" financial services institutions. The idea of Lyft being a financial services provider has me more concerned than optimistic. I don't want a service intermediary controlling the financial future of the person providing the service. Scary.
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.
> Just as modern architects can source the best-in-class parts from around the world to customize a home for its occupants (windows from Italy! toilets from Japan!),
Good analogy. This stuff doesn't apply to 99% of us.
I'll believe this when banks start using Postgres ... it's amazing the stranglehold that Oracle has in this sector (I mean, when considering the price they charge).
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.