What Fintech Delivery Case Studies Show About Launching a Wallet or Lending Product Without Becoming a Bank
If you are a retailer, a platform or a scaling fintech planning a wallet or a lending product, the question in front of you is rarely "which technology?". It is "what do we have to prove, to whom, and in what order?". Investors want a working product before the next round. Regulators and card schemes want controls that were designed in, not added later. Your own team wants a plan that survives contact with third-party systems nobody has fully documented.
Innovify has published case studies covering a buy now, pay later (BNPL) wallet, a property lending platform, a decentralised credit marketplace, a cross-border FX platform, a Mexican digital credit platform, two AI-led products and a property crowdfunding platform. Read one at a time, they are stories about individual clients. Read together, they point to a small number of repeatable delivery patterns. This article draws those patterns out, says where the evidence is strong, and is clear about what it cannot show.
A note on sources before we begin. Everything below comes from Innovify's own published case studies. These are Innovify's accounts and have not been independently verified. The projects are wallets, lending marketplaces, FX and investment platforms. We do not describe any client's licensing or regulatory status beyond what each case study states, and nothing here is legal or regulatory advice. Confirm the position for your own product with your regulatory advisers. Our embedded finance and digital wallet programmes start from the same principle.
The question behind "without becoming a bank"
Most brands and platforms that want to offer a wallet, a credit product or a payment feature do not want to become a bank. They want a product that works, a compliance position they can defend, and a route to scale. The case studies are useful because they show what that looks like in practice for firms that began with a concept and a funding plan rather than a platform.
Three of the eight are UK businesses whose case studies refer to the Financial Conduct Authority (FCA): Zilch, Landbay and Brickowner. Aplazo's case study describes a regulated fintech environment in Mexico, and Betarisk's describes regulated investment banking use, without naming specific rules in either case. Umoja is a cross-border credit marketplace serving emerging markets. Kwanji and Canaree round out the set with a UK FX platform for small and medium-sized businesses and an AI product for private equity.
Across them, five patterns recur.
Pattern 1: Start with the proof, not the platform
The first thing the case studies share is how each engagement began. Innovify's published accounts describe a discovery workshop in every programme, used to define scope, align stakeholders and anticipate technical challenges, followed by a dedicated delivery team.
What the workshop settles is the proof the business needs next. For several clients that proof was commercial rather than technical.
Zilch: a regulated wallet, and evidence before the next round
Zilch, a UK BNPL business offering a digital wallet and Mastercard, wanted a compliant wallet and checkout live within four months. It also needed evidence that its responsible-credit model worked before its next funding round. According to Innovify's case study, the engagement went from the first founder workshops to a production-ready wallet in four months, with Innovify acting as sole product and technology partner alongside the founders.
Landbay and Brickowner: the MVP as a fundraising tool
Landbay, a UK buy-to-let peer-to-peer lending platform, had no internal engineering team and no prior experience of building a minimum viable product (MVP). It needed one to unlock its next funding round. Brickowner, a UK property crowdfunding platform, began with a concept, credible partners and a fundraising plan, but no technical foundation. Its MVP was built to align with its first Seedrs campaign, and the case study reports two successful Seedrs raises of £100,000 each, the second within four months of the first.
Kwanji: validating before building
Kwanji, a UK FX and payments platform for small and medium-sized businesses, started as an idea without a validated product direction. Innovify's published model for it has three phases: Ideate, with research and a clickable prototype; Incubate, with an MVP that kept some back-office steps manual to reduce cost and risk; and Accelerate, with integrations to accounting and ecommerce tools and FX execution partners. The case study says Kwanji won a pitching competition and secured £300,000 of seed investment from Mercia, and reports a valuation above £5 million.
The pattern is consistent. The first release is scoped around the evidence that unlocks the next decision, whether that is a funding round, a regulatory conversation or a pilot. It is not scoped around the full product vision.
Pattern 2: Compliance is a design input from the first sprint
The second pattern is the one most relevant to anyone wondering how to launch a regulated-adjacent product safely.
Zilch is the clearest example. Its constraints were a regulated UK fintech environment, strict PCI DSS and FCA requirements, zero tolerance for latency and several third-party systems with incomplete documentation. Innovify's account says compliance controls were embedded in every layer, with PCI DSS and FCA requirements in scope from the start, on a serverless microservices architecture on AWS with continuous integration and delivery. It reports transactions processed in under 250 milliseconds and says the wallet supports Zilch's PCI DSS certification and FCA approval.
Landbay's case study makes the same point from a different angle. It describes an FCA-compliant model in which compliance was built in by design across data pipelines, investor flows and mortgage underwriting. Brickowner's later challenge was to put processes in place for a regulated, FCA-aligned business as it grew.
Aplazo and Betarisk are described in more general terms. Aplazo needed a secure, scalable, production-ready digital credit platform from day one, in a regulated fintech environment, with one partner owning both product development and cloud infrastructure. Betarisk needed advanced analytics, clear UX and regulatory-ready deployment for investment banking use. Their case studies refer to security and compliance by design but name no specific regulator or certification, so we do not either.
Our reading is that the lesson is practical rather than technical. When compliance is an input to architecture, controls such as data handling, audit trails and access boundaries are part of the first release. When it is an audit at the end, they become rework. That is an interpretation of the published accounts, not a claim any individual case study makes in those words.
Pattern 3: Staged delivery, then a deliberate handover
The third pattern is about what happens after the first release. Several programmes describe a planned sequence: build the MVP, scale the platform with a dedicated team, then transition towards the client's own capability.
- Landbay: Innovify built an enterprise-grade MVP, then a full digital platform with improved core lending workflows on an API-first, cloud-native architecture. The case study describes pathways for internal team expansion, and a dedicated delivery team for new product lines. Midway through, Landbay saw the chance to launch what the case study describes as the UK's first Innovative Finance ISA, with only a one-month window. The case study reports that it was delivered within one month.
- Brickowner: After funding, the MVP moved onto a scalable, full platform with a dedicated development team, structured delivery processes and ongoing technical leadership.
- Umoja: Innovify's engineers worked alongside Umoja's internal engineers on a major pilot rollout in Africa, and the case study credits elastic engineering teams with faster releases.
The point for a product leader is that the case studies treat the first build, the scale-up and the move to an in-house team as three different jobs. Planning for the second and third while delivering the first is what lets a team respond when a window like Landbay's ISA opportunity opens at short notice. Whether any specific handover worked as planned is not something the published pages can confirm.
Pattern 4: Third-party and integration risk is the schedule risk
Wallets and credit products rarely run alone. They depend on card schemes, accounting tools, FX and payment partners and, in some cases, other platforms' APIs.
Zilch's case study is explicit: several third-party systems had incomplete documentation, so Innovify built custom integration layers, stress-tested them and coordinated directly with the third-party teams. Kwanji's Accelerate phase was largely about integration, connecting accounting and ecommerce tools and FX execution partners so that small businesses could act on a rate. Umoja's brief centred on a secure global payment gateway and on completing the last mile of a cross-border payment ecosystem.
The recurring lesson is easy to underestimate. On a wallet or lending programme, the integration list often decides the timeline more than the feature list. Budget time to discover what those systems actually do, not just what their documentation says.
Pattern 5: AI-led products have to earn trust
Two of the eight programmes put AI at the core. They are Betarisk, a risk and analytics platform for investment banking, and Canaree, a product for private equity decision-making.
Both case studies describe the same design challenge. In Betarisk's case it was embedding AI-driven insight into decision-making while keeping the interface clear for institutional users working with complex risk data. In Canaree's, AI had to support decisions without obscuring them, the workflows had to suit private equity users, and a data-heavy product had to earn trust. Canaree's case study says users stay in control and can see how outputs were reached. It describes the result as a production-ready platform rather than a proof of concept.
Betarisk's founder is quoted on the case study as saying Innovify was instrumental in taking the product from concept to market-ready. Neither page gives quantified outcomes. If you are weighing an AI-led product, our AI and ML development work follows the same principle: the model matters less than whether users can see and challenge what it tells them.
What the case studies do not show
A fair reading has to include the limits.
First, these are the delivery partner's own accounts. They are useful as descriptions of how work was approached, and less useful as proof of outcomes.
Second, quantified results are sparse. The figures that do appear, such as four months to a production-ready wallet, under 250 milliseconds for transactions, a one-month ISA delivery, £300,000 of seed investment and two £100,000 raises, are Innovify's reported figures for individual clients. Umoja, Aplazo, Betarisk and Canaree are described largely in qualitative terms.
Third, the case studies do not give you a regulatory blueprint. They show how programmes treated compliance as part of design. They do not set out what any client's regulatory permissions are, and your own product's perimeter will depend on its design, its partners and the rules that apply to you.
The right way to use them is as a checklist of questions to ask any delivery partner. What will you prove first? How will compliance shape the architecture? How will integrations be tested? What is the plan after the first release?
Where Innovify fits
Innovify is a technology partner with deep expertise in banking, financial services, fintech and insurance. We help mid to large businesses, including brands that are not financial companies, build and launch wallets, embedded finance and AI products, and we design compliance in from day one.
The patterns above are how we approach that work: begin with a discovery workshop, scope the first release around the proof that matters next, treat compliance and integration risk as design inputs, and plan the scale-up and handover early. If you are considering a wallet or lending product and want to talk through what your own first release should prove, our Embedded Finance & Digital Wallets team would be glad to help.
FAQ
What do real fintech wallet and lending launch programmes look like?
In Innovify's published case studies they begin with a discovery workshop, then a dedicated delivery team builds a first release scoped around the proof the business needs next, such as a funding round or a pilot. After that comes a scale-up phase, and often a planned transition towards the client's own team. Compliance and integration work run alongside the build rather than after it.
How long does it take to launch a digital wallet?
It depends on scope, but one published example gives a reference point. Innovify's Zilch case study reports four months from the first founder workshops to a production-ready BNPL wallet, with PCI DSS and FCA requirements in scope from the start. Treat that as one client's account rather than a benchmark for your own product.
When should compliance be built into a fintech product?
From the first sprint, according to the approach described in these case studies. Zilch and Landbay both describe compliance controls designed into the architecture from the outset. Retrofitting controls after launch is usually more disruptive, though your regulatory advisers should confirm what applies to your product.
What is an MVP in fintech, and what should it prove?
A minimum viable product is the smallest release that proves the next thing the business needs to prove. In Landbay, Brickowner and Kwanji's case studies, that was evidence strong enough to unlock investment. In a regulated product it may also need to show that core controls work.
Do you need a banking licence to launch a wallet or lending product?
Not necessarily, but the answer depends on how the product is designed and what it does. The case studies describe wallets, lending marketplaces, FX and investment platforms and do not give a general rule. Take advice from a regulatory specialist on your product's perimeter before you commit to a design.
Conclusion
Eight programmes, built for different clients in different markets, show the same shape: prove the next thing, design compliance in, plan for the scale-up, test the integrations and make AI visible to the people who use it. The published case studies cannot tell you whether those patterns will work for your product, but they give you a sensible set of questions to put to any partner. Start with what you need to prove, and let the architecture follow.
