The conventional way to think about the relationship between financial institutions and the fintech ecosystem is as a competition. Fintechs are pulling deposits, lending, payments, savings, and increasingly the broader financial wellness conversation away from primary banking relationships. The institutional response often has been to try to compete with fintech innovation feature by feature: launching the institution’s own savings goal product, the institution’s own roundup-to-savings tool, the institution’s own financial wellness coaching, the institution’s own subscription manager. The strategy is roughly ”build what they build, only inside our experience, before we lose any more ground.”
That strategy is incomplete and what follows from it is usually wrong. The accurate framing of the FI-fintech relationship is not competition. It is a choice between two outcomes: an institution that integrates the fintech ecosystem into its banking relationship, or an institution that gets intermediated by it. The choice is not made primarily through product strategy. It is made through platform architecture, and most institutions have less freedom on the architectural side than they realize.
Why “build it yourself” is an uphill battle
There is a structural reason “build the fintech feature ourselves” tends to underperform, and it has very little to do with how good any individual institution’s product team is.
The fintech companies competing in any given category have been investing in that category, and only that category, for years. The financial wellness fintech has been building financial wellness features for five years. The savings-automation fintech has been iterating on roundup mechanics, goal-setting UX, and behavioral nudges since 2019. The business banking fintech has been refining their onboarding flow against thousands of real onboarding sessions. These companies are not generalists. They are specialists, and their specialization compounds.
An FI building the same features is, almost by definition, building a generalist version of what specialists have spent years perfecting. Even when the institution invests heavily, the outcome is usually a feature that is adequate to the institution’s own customer base but not competitive with what the specialists ship. The institution holds the customer relationship for now, but the customer is increasingly aware that the version of the feature they have access to is not the best version available, and over time they go find the better version. Sometimes they go find the better version while remaining a customer of the FI. Sometimes they don’t.
The institutions that have figured out a different strategy are the ones that have stopped trying to be the specialist in every category and have started trying to be the integration layer for every category. Their customer gets the best-in-class fintech feature, but they get it inside the banking relationship, not next to it.
The fintech specializes. The bank integrates. The customer doesn’t have to choose between the relationship and the capability.
This is the integration strategy, and it is structurally the stronger position for community FIs. The only question is whether your platform can support it.
The architectural test
If you are evaluating your digital banking platform, or evaluating a replacement, the integration question is the one most worth holding the candidates against, and it is almost never asked the right way. The conventional way to evaluate platform extensibility is to ask “does it have an API?” The honest answer is that almost every platform has an API in some form. The question that actually matters is structural.
The test I would propose is three questions in sequence.
1. Is there a purpose-built external API, or is there an internal API exposed externally?
The difference shows up in the documentation. A purpose-built external API has documentation written for external developers: endpoint references, sample code, sandbox environments, authentication patterns appropriate to external callers, and change-management commitments. An internal API exposed externally has documentation written for the team that built it, which an external developer has to translate. If the documentation reads as if it was written for someone who already understood the platform, the API is internal.
2. How many third parties are currently in production on the platform’s API, and how fast did they integrate?
The number of in-production third parties is the truest indicator of whether the API is actually usable by people who do not work at the platform vendor. If the answer is a handful, each of whom took six months and required substantial vendor support, the platform’s extensibility is theoretical. If the answer is dozens, with typical integration times measured in weeks, the platform’s extensibility is real.
3. What is the platform’s posture on partners it has not approved?
A platform that requires every partner to be on an approved vendor list has chosen, structurally, to limit the integration strategy. The institution can integrate with the partners the platform vendor has decided to integrate with. A platform that supports non-approved third parties, allowing institutions to bring their own partners and fintechs to integrate without a formal vendor relationship, has chosen, structurally, to make the integration strategy open-ended. The institution can integrate with the fintech ecosystem as it exists, including the parts of it that the platform vendor has not yet thought about.
The three questions are not independent. A platform that has a purpose-built external API will tend to have many third parties in production, and will tend to support non-approved integrations. A platform without a purpose-built external API will tend to have few third parties in production and will tend to restrict integrations to approved vendors. The pattern is structural.
What “purpose-built for extensibility” looks like in practice
We have spent the past several years at Lumin building Lumin API specifically to be the integration layer for the FI-fintech relationship. The architectural choices are visible in what we have built so far: a standalone API product designed specifically for FIs and third-party vendors to consume; 40+ ready-to-use endpoints organized across eight functional categories (accounts, money movement, transactions, user data, marketing, and others); a token-based authentication model designed for external callers rather than retrofitted from internal use; full developer documentation and sandbox environments; and a model that abstracts away the underlying banking core, so a fintech that integrates once with Lumin API can reach FIs across multiple cores without separate integration work for each.
The pattern in the data is the part worth pausing on. We currently have seven third-party integrations in production and another 20+ in progress or queued. The API is processing roughly two million calls a month across our client base. The integration times for our recent partner cohort tell the story most clearly: a subscriptions management vendor went from kickoff to production in four weeks and saw 4,000 enrollments within ten days of launch; and a business banking insights vendor integrated in 40 engineering hours and now serves 515 business users across five financial institutions on a single shared integration.
40+
ready-to-use API endpoints
20+
partner integrations in progress
~2 million
API calls processed each month
The “integrate once, reach many” claim is not theoretical for partners building on Lumin API. It is operational.
The choice in front of you
The fintech ecosystem is not going to stop expanding. It is going to expand faster, into more categories, with more specialized players, and with shorter cycles between when a category becomes possible and when a competitor in that category enters your customers’ financial life. The institutions that will hold their ground are those whose digital banking platform lets them adopt the fintech ecosystem rather than compete with it. The institutions that will lose ground are those whose platform forces them to build everything themselves, slowly, and ship it second.
If extensibility is a strategic priority for your institution this year, and I would argue it should be, the question to hold yourself to is not “does our platform have an API.” Almost every platform has an API. The question is whether the API is purpose-built, whether the platform has a meaningful number of partners actually shipping on it, and whether the platform supports integration with parts of the fintech ecosystem its vendor has not approved.
If the answers are not what you want them to be, the underlying issue is architectural, and the architectural issue compounds over the next several years in ways that are difficult to reverse later.
The institution that figures out the integration strategy now will be in a structurally different position in two years from the institution that is still trying to build the next fintech feature in-house.
The fintech ecosystem is going to be part of every community FI’s customer relationship by the end of this decade. The only question is whether it is going to be part of it through you, or around you.
Christina Bondoc
Product Management, Lumin Digital
