Modern Merchant Onboarding for Large Banks

Modern Merchant Onboarding for Large Banks

The economics of SMB banking have moved underneath the largest financial institutions. According to Jack Henry's 2025 Strategy Benchmark, 80% of bank and credit union leaders plan to expand small business services in 2025 and 2026 — chasing what BAI's 2026 Banking Outlook frames as a $130 billion SMB revenue opportunity that has, until recently, been split between credit cards and a fast-growing fintech challenger set. The reason is not pricing. The reason is the front door. Fenergo's 2025 Financial Crime Industry Trends report found that 70% of financial institutions lost clients in the past year due to slow or inefficient onboarding — the highest rate it has recorded — with average client abandonment now hovering around 10%. For a tier-one bank pushing merchant services beyond enterprise into the SMB and ISV segments, the onboarding journey has become the single most expensive piece of architecture in the building.

Ritvik Pandya is a Software Engineering Manager at J.P. Morgan Chase and a member of the IEEE Consumer Technology Society, with more than seventeen years of experience designing distributed systems for global payment platforms. He has led the architecture and delivery of merchant onboarding platforms that span workflow-driven KYC and CIP compliance, credit review, underwriting, and partner integration across multiple regions. His perspective on why traditional onboarding stacks crack under SMB and ISV demand begins with a structural observation: enterprise compliance machinery and self-service speed were never designed to live in the same system.

We spoke with Pandya about the structural tension banks face when expanding into SMB and ISV segments, the architectural patterns that resolve it, and what most institutions are still getting wrong about reusability across portals and partner ecosystems.

Banks have always done compliance well. Why has SMB and ISV onboarding become a hard problem now?

Compliance was never the bottleneck. The bottleneck was that enterprise onboarding workflows were designed for relationship managers, not for self service. When a corporate treasury client comes through the door, they expect a six week cycle, a dedicated banker, several rounds of documentation, and a human in the loop at every gate. None of that translates to an SMB owner who wants to start accepting payments before lunch. The SMB segment has been trained by fintech challengers to expect approval in minutes, not weeks, and the gap between those two operating models is where banks are bleeding clients.

The harder part is that the underlying compliance work has not gotten lighter. KYC, CIP, beneficial ownership verification, sanctions screening, and underwriting all still have to happen. According to Fenergo, average annual spend on AML and KYC operations now sits around $73 million per institution, and McKinsey estimates that banks typically dedicate 10 to 15% of their workforce to KYC and AML operations. Banks cannot just delete the compliance steps to move faster. They have to redesign the architecture so that compliance happens alongside the customer journey instead of in front of it. That is the actual engineering problem.

What does the structural tension look like in practice when a bank tries to serve enterprise, SMB, and ISV in the same platform?

It looks like three completely different products being asked to share a single backend. Enterprise clients want configurability, account hierarchy, and a long onboarding tail. SMBs want a clean self service path with as few gates as possible. ISVs want an embedded experience where their developers can integrate the bank's onboarding into their own product surface. Each of those segments has different speed expectations, different compliance triggers, different UI surfaces, and different regulatory profiles depending on the geography. If you try to serve all three with the same monolithic flow, you end up with the worst of every world.

The institutions that get this right stop thinking of onboarding as a single pipeline and start thinking of it as a set of composable journeys. The compliance core is shared. The orchestration is shared. But the surfaces, the entry points, and the workflows are tailored to each segment without rebuilding the compliance logic underneath every time. That is a deceptively hard architectural shift because most legacy banking platforms were not built with that separation in mind. The compliance logic is welded into the UI, the UI is welded into a single deployment, and any change to one ripples through the whole stack.

Micro Frontend and Backend for Frontend patterns have started showing up across financial services. Why are these emerging now as the answer?

Because they solve the problem of reuse without forcing teams into lockstep. A Micro Frontend architecture lets each portal, a merchant facing onboarding flow, a partner bank's branded experience, an ISV's embedded surface, plug into the same set of independently deployable UI components. The compliance logic, the document upload, the KYC capture, the underwriting forms, those become reusable building blocks. Each portal assembles them however it needs to, but nobody is rebuilding KYC from scratch every time a new partner joins.

The Backend for Frontend pattern handles the orchestration side. Instead of every UI surface talking directly to fifteen downstream systems and trying to manage that complexity itself, you put a thin orchestration layer in between that aggregates, transforms, and shapes data for each specific frontend. For a bank, that is enormous, because your downstream landscape is a mess of legacy systems, credit ops platforms, document stores, partner banks, and risk engines that all evolve on their own timelines. The BFF gives you a place to absorb that complexity without leaking it into every UI. Together, MFE and BFF let you ship faster, isolate failure domains, and onboard new partners without the architectural tax that legacy stacks impose.

Where does this break? What's the failure mode most teams underestimate?

The hardest failure mode is governance, not engineering. Once you have ten teams shipping into the same Micro Frontend platform, you have to decide who owns the contract between components, who owns the design system, and who has the authority to break compatibility. If you do not solve that early, you end up with a fragmented experience that looks like a single product but behaves like ten different ones glued together. The compliance team has its own opinions about what data has to flow through which gate. The risk team has its opinions about isolation. The partner banks have their opinions about branding and data residency. Architecture cannot resolve those conflicts. Architecture can only enforce the resolution once it has been made.

The second failure mode is the temptation to over fragment. Micro Frontends are powerful, but if you split the UI into a hundred tiny components, the cognitive overhead of integration overwhelms the benefit. The teams I have seen succeed treat the boundaries the same way you treat microservice boundaries. You split along domain lines, not technical lines. KYC is one component because it is one domain. Credit review is another. The integration cost of crossing a component boundary should be lower than the cost of having that boundary live inside a single team's deployment. If it is not, you have drawn the line in the wrong place.

You hold dual graduate degrees in software engineering and computer applications. How did that academic foundation shape the way you approach problems like this?

Honestly, the most useful discipline I keep coming back to, and one I have written about in my work on building self-healing systems, is problem decomposition. Distributed systems coursework forces you to internalize a few uncomfortable truths early. The network is not reliable. Latency is not zero. Components fail independently. Partial failure is the normal state of the system, not an exception. Those are not abstract academic ideas. They are the operating reality of every payment platform I have ever worked on.

When you are designing an onboarding platform that has to coordinate across credit ops, underwriting, risk, document storage, and a dozen partner systems, the academic training is what tells you to design for partial failure first and optimistic happy paths second. A lot of teams do it the other way around. They design for the happy path, then bolt on resilience when the system starts breaking under real load. The architecture I just described, MFE plus BFF plus event driven orchestration, is essentially an embodiment of those principles. Each component fails in isolation. Each surface degrades gracefully. The system as a whole keeps working when individual pieces do not.

Before your current role, you spent significant time at Apple and PayPal. How did those environments shape your thinking on platform reusability?

PayPal in particular taught me what reusability actually costs. When you are running a global payments platform that has to onboard sellers across marketplaces, subsidiaries, geographies, and product lines, the only way to ship at speed is to invest aggressively in shared platforms. But shared platforms have a real organizational cost. You need product owners who think about the platform as a product. You need contracts between teams that survive personnel changes. You need a culture that rewards engineers for building things other teams adopt, not just for shipping their own features. Most companies underestimate how much social and organizational scaffolding a shared platform requires.

Apple's environment reinforced a different lesson, which is that the user experience floor is not negotiable. You can build the most architecturally elegant backend in the world, and if the experience on the surface is inconsistent, it does not matter. That perspective is exactly what is missing in a lot of bank built SMB experiences. The architecture has been modernized, the compliance is solid, the systems work, and the experience still feels like it was designed by a committee. Both things have to be true at once. The architecture has to support reuse, and the surface has to feel intentional. Anything less and you lose the segment to a fintech that took both seriously from day one.

What's still unsolved? What's the question you most want the industry to get right over the next few years?

Two things. First, the problem of cross institution identity for businesses. Right now every bank, every fintech, every payment processor onboards a merchant from scratch, runs its own KYB checks, builds its own risk profile, and treats the work as proprietary. The merchant goes through the same documentation upload five times in a quarter to participate in five different financial relationships. There is real product opportunity in shared, portable business identity infrastructure that lets a verified merchant carry their compliance posture between institutions, with appropriate consent and auditability. Nobody has cracked it yet, but the demand is obvious.

Second, the question of how far the SMB and ISV onboarding architecture can stretch into entirely new product categories. Real time payment rails, embedded credit, stablecoin settlement, account to account flows. Each of these is going to demand the same self service speed that SMBs already expect for basic merchant services. The institutions that have done the architectural work, MFE based reusability, BFF orchestration, event driven workflows, will treat each new product as a configuration problem. The ones that have not will treat it as a re platforming project, and they will lose another year to the fintech competitors that did the work earlier. The window for catching up is narrower than most institutions believe.