DEV Community: Aislin Keir

KYC vs KYB vs AML Compliance: How to Structure Fintech Onboarding the Right Way

Aislin Keir — Fri, 31 Jul 2026 11:32:14 +0000

The global identity verification market is on track to nearly quadruple this decade, from around $9.87 billion in 2022 to a projected $33.93 billion by 2030, according to Grand View Research. That growth is largely regulatory pressure and fraud prevention pushing companies to invest in better onboarding infrastructure, not just a nice-to-have feature anymore. KYC, KYB, and AML sit right at the center of that spending, and treating them as one interchangeable check is a common way that investment ends up misallocated.
A lot of onboarding flows start with a single verification flag on the user record, one field that flips to true once someone passes the initial check. That works fine for consumer signup. It gets more interesting the moment a business is the one onboarding instead of a person, because at that point the flow needs to answer a few different questions at once, not just one.

Why KYC vs KYB vs AML Compliance Needs Different Data Shapes

Each of the three answers a different question, about a different subject, on a different schedule. Treating them as one flat check is usually where the architecture starts to crack.

KYC and KYB verify different subjects

KYC :Know Your Customer verifies a person, an identity document, an address, sometimes biometrics. KYB: Know Your Business verifies an entity, registration paperwork, ownership structure, and the humans who ultimately own it, which can take real digging to map out for a business with layered ownership.

Giving both the same shape works fine when your customer is always an individual. It gets a lot more interesting once a business shows up, because a business needs room for an ownership graph, not just one name field. Designing that in from the start makes it much easier to trace who actually owns an entity later, rather than reconstructing that picture after the fact.

AML runs on a different clock

Anti Money Laundering is a different kind of problem entirely. KYC and KYB are naturally suited to running once, at the door, verify, gate the signup, move on. AML needs to be continuous: transaction monitoring, sanctions re-screening, and pattern detection running against every account well after onboarding is done, because the behavior it's designed to catch tends to show up over time, not at signup.

Designing for This Early Pays Off

None of this needs to be complicated, it just needs to be intentional. A couple of structural decisions made early save a much bigger rebuild later.

Separate the compliance profile from the account

Separating the compliance profile from the account itself makes room for this naturally. An individual profile and a business profile can stay distinct shapes, with a business profile referencing its associated individual profiles for beneficial owners.

Route AML through its own pipeline

Routing AML through its own event-driven pipeline instead of folding it into signup keeps it running the way it's meant to, continuously, rather than tied to a moment that already passed.

This is usually where fintech teams bring in outside engineering support to get the architecture right from the start, with companies like Bacancy Technology helping build onboarding infrastructure where KYC, KYB, and AML are structured as separate components within financial IT solutions rather than forcing one workflow to handle every scenario.

Getting KYC vs KYB vs AML compliance modeled correctly from day one is easy to fix while the schema is still on a whiteboard, and a lot harder to unwind once a business customer's ownership graph doesn't fit anywhere in the system.

Embedded Finance vs Open Banking: Which One Should You Actually Build?

Aislin Keir — Sat, 25 Jul 2026 15:07:36 +0000

I see embedded finance and open banking used almost interchangeably in engineering conversations all the time, and it’s causing teams to architect the wrong thing before a single sprint kicks off. The embedded finance vs open banking question actually has a clean answer when you strip away the jargon - they’re built on different regulatory foundations and different data flows, and picking the wrong one early means rebuilding core integration work months down the line. The CFPB’s Personal Financial Data Rights Rule, which is being implemented in phases through 2030, is explicitly built on the open banking model and gives consumers the right to share their bank data with third parties. That’s a very different regulatory foundation than what embedded finance is based on and knowing the difference does matter before you even write a single line of integration code.

What is Embedded Finance?

For embedded finance, that means embedding a financial feature into a non-banking product. Think of Uber offering drivers instant payouts or Shopify giving merchants a loan inside their dashboard. The financial feature isn't the product; it's a layer added to something else, sitting on top of a bank's licence and an infrastructure provider's APIs.

What Is Open Banking?

Open banking means connecting to a customer's existing bank accounts, with their consent, to pull data or trigger a payment. A budgeting app that shows you spending across every account you own is open banking. Nothing gets embedded into anything; you're just reading (or moving money through) accounts that already exist elsewhere.

Embedded Finance vs Open Banking: The Core Difference

Here's the distinction that actually matters when you're deciding what to build. Embedded finance vs open banking really comes down to whether you're creating a financial product or connecting to one that already exists:

When Embedded Finance Is the Right Fit?

Weighing embedded finance vs open banking usually starts here: if your product already has a user base and a natural moment where money changes hands, like a driver finishing a ride, a merchant needing working capital, embedded finance usually wins. You're not asking the user to go connect an external account, you're extending a workflow the user is already in. The tradeoff is real technical heft. Now you’re on the hook for a financial product that lives inside your app, even if a licenced partner is underwriting the actual risk.

When Open Banking Is a Good Fit?

If your product is about understanding or moving money that the user already has somewhere else, such as budgeting, lending decisions based on real transaction history or account to account payments, then open banking is the right model. You're not creating a new financial product, you're building a bridge to existing ones. This tends to be lighter weight to get started, but depends heavily on the reliability and coverage of whatever aggregator or API layer you hook through.

Where Banking as a Service (BaaS) Fits in Both?

This is the part that trips people up when they're weighing embedded finance vs open banking. Banking-as-a-Service isn't either one, it's the plumbing underneath embedded finance specifically, the APIs that let you issue accounts, cards, or loans without holding a banking license yourself. If you're building embedded finance, you're probably using a BaaS provider. If you're building open banking, you're not, you're connecting to other institutions' data, not issuing your own financial products.

Technical and Implementation Considerations

Whichever side of embedded finance vs open banking you land on, the actual engineering weight shows up in the same three places.

Identity and Compliance

Embedded finance carries KYC/AML obligations on whatever product you're issuing. Open banking carries consent management and data-sharing standards instead, the CFPB rule mentioned earlier is exactly this kind of requirement. Different regulatory surface, but neither one is optional.

Provider Reliability

You inherit whatever your infrastructure partner ships. A BaaS provider's uptime becomes your uptime. An aggregator's bank coverage and connection stability become your coverage and stability, whether or not that's disclosed clearly in their docs.

Reconciliation

Money or data moving through a third party still has to match up cleanly on your side. This is the part that quietly eats the most engineering time post-launch, and it's rarely scoped accurately upfront.

Getting this integration right the first time, rather than rebuilding it after a partner's API changes or a compliance gap surfaces, is usually where fintech web development services come in, handling the parts of this that sit outside a typical product team's day-to-day skill set.

Making the Right Call for What You're Building

The decision between embedded finance vs open banking really comes down to one question: are you building a financial feature or connecting to one that already exists? Get that answer right and the rest of the technical roadmap, the integrations, the compliance surface, and the partner dependencies follow. If you get it wrong, you end up building integration work for a model that was never the thing you were shipping.

If you're still working through which model fits, or you're past the decision and need to actually build it, that's usually where bringing in fintech app development experience early saves the most time before the architecture gets locked in around the wrong assumption.

LLM Use Cases in Finance: Architecture, Real-World Applications, and Best Practices

Aislin Keir — Tue, 21 Jul 2026 04:41:40 +0000

Financial institutions have moved beyond experimenting with large language models, they’re learning how to run them in production now. Building a deployment that actually works is not simply about picking the latest model but integrating enterprise data, meeting regulatory needs, and making the outputs reliable enough for day-to-day financial operations.
Forbes reported this July that JPMorgan Chase's internal LLM Suite is now used by more than 230,000 employees, with efficiency gains of 30 to 40% and roughly $2 billion in annual savings from its AI initiatives. Numbers like that describe a technology already embedded in daily operations, not a pilot programme. We cover how enterprise LLM deployments in finance are actually architected, where LLM use cases in finance are already delivering value, and what separates teams getting real production results from teams still stuck testing a demo

LLM Architecture in Finance: How Enterprise Deployments Work

Most successful LLM use cases in finance run into the same underlying decision: how domain knowledge actually gets into the model. There are three approaches to that, and picking the wrong one is usually why a project stalls before it reaches a single use case.

Prompt Engineering

It puts context into the query itself. It is very easy to use and involves minimal infrastructure; however, this technology is limited to the information provided in one prompt only, without the opportunity to use any previous context in the process.

Retrieval Augmented Generation (RAG)

RAG retrieves relevant documents from a knowledge base and feeds them into the query along with the query at query time. This means that the information is current and traceable, which is what you need in a regulated environment.

Fine-tuning

This trains the model directly on proprietary data. Financial data changes constantly, so a fine-tuned model goes stale the moment its training cutoff passes, and tracing which training example shaped a given output is close to impossible, a real problem when a regulator asks how a decision was reached.

A simplified version of the most common enterprise pattern looks like this:

Core Banking / Document Repository
       ↓
RAG Retrieval
       ↓
LLM Reasoning
       ↓
Draft Output
       ↓
Human Review
       ↓
Production Output

While most of the attention is paid to the choice between RAG and fine-tuning, many finance teams find that neither is the hardest part. The actual bottleneck is connecting an LLM to systems that were never meant to expose knowledge cleanly in the first place.
Building an LLM application is usually the easy part. Connecting it securely to legacy banking platforms, document repositories, identity systems, and audit controls is where most of the engineering effort lies, making financial IT services expertise far more valuable than model selection alone.

Enterprise LLM Use Cases in Finance

Now that we have the architecture in place, the question becomes: where LLM use cases in finance actually add value? In practice, adoption has focused on a few high-impact workflows.

Document Intelligence for Compliance

This is still one of the more mature LLM use cases in finance, especially for regulated institutions that process large amounts of documentation. An LLM reads a new regulatory filing, summarizes it, and flags clauses that changed from the prior version, routing it to whoever owns that area. JPMorgan's own DocLLM is a public example of this kind of document understanding work. The retrieval layer matters enormously here, since a hallucinated summary of a regulation is a liability, not a convenience.

Credit Memo and Research Drafting

An analyst feeds the model the underlying financials and source documents, and it produces a first-draft memo a human then edits rather than writes from scratch. The value comes from removing the blank page, not replacing judgment.

KYC and Entity Resolution

KYC has quickly become one of the fastest-growing LLM use cases in finance because of the volume of unstructured documents involved. LLMs extract and cross-reference entity information across incorporation documents, sanctions lists, and ownership structures, tasks that used to mean manually reading inconsistent formats one at a time.

Internal Knowledge Search

Employees ask a plain-language question and get pulled answers from internal policy documents or past deal memos instead of digging through a shared drive nobody fully trusts is current. Florida's SouthState Bank has taken this approach, training an LLM on its own internal documents for exactly this kind of search.

Customer-Facing Assistants

Bank of America's Erica is one of the better-known examples of an assistant handling account questions and routine transactions at scale. The more interesting shift is these assistants increasingly hand off to a human with full context already assembled, so the customer never repeats themselves.

Natural Language Queries Over Structured Data

Analysts ask a question in plain English and get it translated into the right database query behind the scenes, useful because plenty of strong financial analysts aren't strong SQL writers.

Contract and Agreement Review

LLMs flag non-standard clauses in loan agreements or vendor contracts against a firm's standard templates, cutting the first review pass from hours to minutes.

Regulatory Change Monitoring

Instead of a team manually checking dozens of regulatory bodies for updates, an LLM-based system watches constantly and produces a plain summary of what's new and who it affects.

Best Practices for Enterprise LLM Deployments

As these LLM use cases in finance move from pilots into production, organizations are discovering that deployment quality matters more than model choice. The deployments that make it to production converge on the same handful of practices, no matter which model sits underneath them.

Prioritize Retrieval Quality Over Model Choice

Picking the best LLM gets most of the attention, but if the retrieval layer feeds it the wrong or outdated documents, model choice barely matters. Most of the real engineering effort in a working deployment goes into the data pipeline, not the model.

Build Evaluation Into Every Release

Teams that succeed define what a good output looks like before they ship anything, then keep testing against that bar as the model or data changes. A demo that worked once doesn't guarantee it keeps working in production.

Keep Humans in the Review Loop

Every working deployment still has a person checking outputs before anything reaches a client or a regulator, by design, not as an afterthought. This is the piece that keeps the system auditable.

Plan Enterprise Integration From Day One

Connecting an LLM to the core banking system, the document repository, and the compliance database is rarely a footnote. Underestimate it upfront, and projects stall for months waiting on access nobody scoped early.

Strengthen Governance and Security

Clear rules about what the model can access, retain, or generate need to exist before launch, not get bolted on after something goes wrong. That’s what decides if you can trust the system with anything sensitive at all. As enterprise adoption matures, the successful LLM use cases in finance are less about model size and more about governance, integration, and reliable data.

The Real Advantage Isn't the Model; it's the architecture

None of this is really about picking the right model anymore. Foundation models evolve quickly, making today's leading model tomorrow's baseline. What determines long-term success is an architecture that allows organizations to adopt better models without rebuilding the surrounding systems.

That kind of flexibility rarely comes from a single tool rollout. It's usually the result of a financial services digital transformation effort built around modular, model-agnostic infrastructure from the start, the kind that lets a firm change what's under the hood without touching everything built on top of it. The financial institutions leading LLM adoption and delivering the most successful LLM use cases in finance aren't necessarily the ones using the newest model. They're the ones that built an architecture capable of evolving as the technology changes.