The Problem With Disconnected Lending and Payment Stacks
This is one of those origin stories that does not start with a brilliant idea on a napkin. It starts with a production incident at 2am. As most honest fintech origin stories do.
The specific incident does not matter — it involved a disbursement that had been processed, a compliance flag that had been raised in a separate system six hours later, and a reconciliation process that took three days to confirm that the payment had in fact gone to the right place and that the compliance flag was a false positive. Three days. For something that should have been a five-minute check. The payment was fine. The borrower was fine. The hours were not fine.
What made it worse was knowing that the problem was not an edge case. It was the architecture. And we had built that architecture. Not badly — we had built it the way everyone builds fintech infrastructure when they are working with the tools the market provides. You pick the best loan origination system. You connect the best AML tool. You route payments through a processor with solid ACH and Fedwire support. You build the integration layer that holds it all together and you hire an engineer to maintain it and you move on.
And then at 2am you are debugging a reconciliation problem that exists entirely in the gap between two systems, and you are thinking: there has to be a better way to do this.
The Environment We Came From
To understand why Metagens.ai was built the way it was, it helps to understand the environment we came from. We spent years building financial infrastructure inside some of the most demanding BaaS (Banking-as-a-Service) environments in the US market. Not designing it. Building it. Writing the code, debugging the production issues, shipping the features, and operating the systems that financial institutions and fintechs depended on to run their lending and payments operations.
In that environment, you see the fintech infrastructure market from the inside. You see which parts of the standard stack work elegantly and which parts are held together by carefully maintained integration code and a lot of institutional knowledge about which combinations of inputs produce unexpected outputs. You see which compliance workflows are genuinely automated and which are nominally automated but require a human to check three screens and manually cross-reference two systems before they can be signed off.
You also see the fintechs that are trying to build lending products on top of this infrastructure. You see what the integration work costs them. You see how long it takes. You see the engineering talent that gets allocated to maintaining the connections between systems rather than building the product features that actually differentiate the business.
At some point — and it is a slow realisation, not a sudden one — you start doing the maths on how much time and money is going into the infrastructure layer versus how much value is coming out of it. The numbers are not great.
The fintech lending stack problem is not a vendor quality problem. The vendors are often excellent. It is a structural problem. When compliance is a module you add and the ledger is a system you connect, the gaps are architectural — and architectural gaps do not get fixed by updating a configuration.
The Specific Problem We Kept Running Into
There is a pattern that repeats itself across every fintech that is building a lending product from assembled infrastructure. We have seen it enough times to describe it precisely.
A fintech team decides to launch a lending product. They select a loan origination system — probably one of the well-known API-first platforms in the market. They connect a KYC provider. They add AML monitoring through a compliance specialist. They wire in a payments processor for ACH and Fedwire disbursements. They build a core banking ledger — either by extending the origination system, licensing a separate tool, or building something internally that is always described as ‘temporary’ and never replaced.
The integration work takes somewhere between eight months and fourteen months, depending on the team size and the complexity of the loan product. During this time, they are not building product features. They are building plumbing. When they finally get to market, they are roughly a year behind the timeline they originally pitched to their investors.
Once they are live, the ongoing maintenance load is substantial. API versioning across five vendors. Compliance data reconciliation. Support escalations that bounce between vendor queues because the failure happened in the gap between two systems and nobody’s SLA covers the gap. Platform updates from one vendor that break the integration with another.
And then there is the compliance question. Which is not whether they have a compliance programme — they do, they built one, they connected the right tools. The question is whether the compliance programme functions the way they think it does. Whether the AML screening is genuinely contemporaneous with the transaction or whether there is a timing gap that creates a compliance exposure they are not aware of. Whether the audit trail they would present to a regulator is actually a single coherent record or an assemblage of exports from four systems.
These are not exotic problems. Every fintech lending team we have ever worked with or alongside has dealt with some version of all of them. They are the standard experience of building a lending product on assembled infrastructure.
The Decision to Build
The decision to build Metagens.ai was not made in a moment of frustration after a late-night production incident. It was made after enough of those incidents and enough conversations with fintech teams dealing with the same structural problems that the pattern became impossible to unsee.
The question we kept coming back to was: what would the lending infrastructure stack look like if you built it natively, from scratch, with every layer in the same codebase, sharing one data model, designed to be operated by a fintech team of five rather than a bank IT department of fifty?
Not assembled from best-in-class parts. Not a composable architecture where you select and connect modules. A single system lending, AML compliance, payments, core banking, cards, and security built as one thing, deployed as one thing, maintained as one thing.
The answer to that question is Metagens.ai.
What Building It Actually Took
Building a full-stack fintech infrastructure platform natively is not a small project. We are not going to pretend otherwise.
The lending module alone — origination, automated decisioning, KYC integration, loan management, revolving credit, payment mandates — required building a significant amount of functionality that most platforms source from third parties. But because we were building it as part of a native stack rather than as a standalone product, every design decision could be made with the AML engine, the core banking ledger, and the payments rails in mind. The data model was designed once, shared across all layers, and never needed a translation layer because there was never a separate system to translate between.
The AML engine was the layer that benefited most from the native architecture decision. When AML compliance is built into the same codebase as the lending module, the screening logic has access to the complete transaction context — not just the fields passed in an API call, but the full origination history, the complete customer record, the prior compliance events, and the real-time ledger state. SAR generation, OFAC screening, PEP detection — these are not external calls that happen after the fact. They run in the same transaction as the lending event. There is no gap between the financial event and the compliance record. They are the same record.
The payments layer was where the ISO 20022 decision was made. Most payments infrastructure built before 2020 started with legacy message formats and migrated to ISO 20022. We built on ISO 20022 from day one — not as a migration target but as the native data model. ACH, Fedwire, and ISO 20022 structured payments are all native to the platform, not routed through a payments processor that manages the rail on our behalf.
The core banking ledger is where the architecture advantage is most visible in daily operation. When a loan is disbursed, the ledger records it in the same transaction — not via an API call to a separate core banking system on a two-second delay. When a payment is received, the balance updates in real time. When the AML engine flags a transaction, the compliance record and the ledger entry are the same database record. Reconciliation between the ledger and the compliance data is not a process. It is not a question. The data is always consistent because there is only one data source.
Metagens. Meta, from the Greek — beyond, above, transcending. Gens, from the Latin — to generate, to create, to bring into being. The name is about generating outcomes that go beyond what the obvious solution produces. Beyond the assembled stack. Beyond the managed-service dependency.
What We Are Building Toward
Metagens.ai launched with lending infrastructure as the primary focus for a specific reason: the lending product market in the US is where the assembly problem is most acute, where the compliance requirements are most demanding, and where the deployment timeline — 6 to 8 weeks for a full-stack lending operation — is most differentiated from the market standard of 8 to 14 months.
The payments platform — ACH, Fedwire, ISO 20022 native — is built and tested. US entity registration is in progress. When that completes, the payments layer opens for US market customers. Until then, it is available for architecture review and evaluation by teams planning their payments infrastructure.
The longer-term vision is what the name implies. A fintech team should be able to launch any financial product — lending, payments, cards, deposit accounts — on a single infrastructure platform that they own, that they control, and that does not require a services premium to function. The technology to make this possible has existed for years. It has not been assembled into a single native stack because assembling the parts was the market model that worked, and nobody in a position to build the alternative was sufficiently frustrated with the status quo to do it instead.
We were sufficiently frustrated with the status quo.
For the Team That Is Currently in Month Nine of an Integration Project
If you are reading this and thinking ‘this is exactly what we are dealing with,’ then this article was written for you. Not as a sales pitch — a 3,000-word origin story is a strange sales pitch — but because the people who built Metagens.ai spent enough time in your situation to understand exactly what it is like.
The integration work does end. The platform goes live. And then you have a lending product that works, that is compliant, that processes real loans for real borrowers. That outcome is worth the work.
The question is whether the architecture underneath it will serve you as you scale. Whether the compliance architecture will hold up when transaction volumes are high enough to attract regulatory attention. Whether the audit trail is the kind of complete, contemporaneous record that an examiner is looking for. Whether the engineering team that got you to market has the bandwidth to maintain five vendor integrations and still build the product features that drive growth.
Those are architecture questions. And they are answered most cleanly before the architecture is built.
If you want to see what a native full-stack fintech infrastructure platform actually looks like — not in a slide deck, but in a working product — request a demo. The people you will speak to are the people who built it. They will tell you honestly whether it fits your situation. And if it does not, they will tell you that too.
Because the platform we built deserves to be on the right lending operations. Not just any of them.
