There’s a role showing up across fintech that barely existed a few years ago: the compliance product manager.

And it makes complete sense.

Compliance isn't a static set of policies that gets implemented once. It has to evolve alongside the product.

Every time a fintech enters a new geography, launches a new product, adds a payment rail, onboards a new type of customer, or changes how money moves through its platform, the compliance logic has to evolve with it. Different customers need different onboarding requirements. New products introduce new risks. New geographies require different rules. New transaction patterns require different monitoring.

In many ways, compliance logic is part of the product itself.

For a regulated financial institution, approving a customer or allowing a transaction isn't some back-office process adjacent to the product. It is the product. If you can't onboard the customer or approve the transaction, there is no revenue.

And the logic governing those decisions increasingly sits with Compliance.

Who can be onboarded? What information do we need? When does a transaction require additional review? What activity should trigger an RFI? When should funds be held? When does a customer's behavior change their risk profile?

Those decisions sit directly in the critical path of the business — but actually implementing them usually requires product and engineering.

That's one of the reasons I think fintechs are investing so heavily in compliance product managers.

They sit between Compliance and Engineering, translating constantly evolving regulatory and risk requirements into the logic, workflows, integrations and controls that actually run inside the product.

And because the product never stops evolving, neither does the compliance infrastructure behind it.

The question is: should every fintech have to keep building that infrastructure itself?

The engineering dependency problem

Compliance product managers solve a very real problem.

They understand enough about regulation and compliance operations to know what the team needs, and enough about product and engineering to translate those needs into something that can actually be built.

At larger fintechs, that role can be critical.

But I think the rise of this role also tells us something about the way compliance infrastructure has evolved:

Why does so much compliance logic still need to be built by engineering in the first place?

Compliance teams are constantly competing for engineering resources against revenue-generating products, customer experience, infrastructure and everything else on the roadmap.

And compliance is never finished.

Rules change. Products change. Regulations change. Risk appetites change. New vendors and data sources get added. New jurisdictions introduce different requirements.

So even companies that have invested heavily in building their own compliance infrastructure end up maintaining what is effectively an internal compliance software platform.

I've seen this from both sides. Before building Corsa, my co-founder and I operated our own payments company. Compliance required a huge amount of internal building and ongoing engineering maintenance - and despite all of that investment, processes were still fragmented and manual.

That experience was a big part of what ultimately led us to build Corsa.

Point solutions haven't really solved this

The industry has added more and more compliance software, but in many cases that has actually increased the orchestration problem.

There’s one provider for KYC. Another for KYB. Another for sanctions. Another for blockchain analytics. Another for transaction monitoring. Another for case management. Another for Travel Rule.

Then there are the company's own internal systems, customer data, transaction data, support tools and risk models.

Each tool solves an important problem, but someone still has to connect everything.

Someone still needs to determine what happens when a signal comes back.

If this customer has this risk score, receives funds from this counterparty, triggers this monitoring rule and has this screening result — what happens next?

Do we request information? Escalate the alert? Restrict the transaction? Update the customer's risk score? Open a case? File a SAR?

That orchestration layer is where a huge amount of compliance product and engineering work now lives.

The problem gets harder as fintech becomes multi-rail

This is especially important as the line between fiat and digital assets blurs.

A stablecoin payment company might onboard a business, receive fiat through a bank account, convert it into a stablecoin, move it on-chain, convert it back into another currency and pay it out through a local payment rail.

From the customer's perspective, that's one transaction.

From a traditional compliance stack's perspective, it might be four or five completely separate systems.

The compliance team shouldn't have to investigate each piece independently. They should be able to understand the behavior of the customer across the entire flow.

And every time the company adds a new rail, product or geography, that logic needs to evolve again.

AI makes the infrastructure question even more important

AI can now do a meaningful amount of the work that historically required manual investigation.

It can triage alerts, research customers, analyze transaction behavior, review documents, draft investigation summaries, generate RFIs and help prepare regulatory filings.

But deploying AI inside compliance isn't as simple as adding a chatbot.

The models need the right context. Their actions need to be permissioned. Decisions need to be explainable and auditable. Sensitive customer data needs to be handled appropriately. And humans need to remain in control where judgment is required.

That makes the underlying compliance infrastructure even more important, not less.

This is what we built Corsa to change

Corsa is, in many ways, the compliance product layer that fintechs have been building internally.

It gives Compliance the infrastructure to turn policy and risk decisions directly into rules, workflows and controls — across onboarding, customer risk, transaction monitoring, investigations, RFIs and regulatory reporting — without needing Engineering to build and maintain each one.

For smaller or earlier-stage fintechs, that can remove much of the need to build a dedicated compliance product function in the first place. Instead of hiring product managers and allocating engineers to build the infrastructure between Compliance and the product, Corsa provides that layer out of the box.

For larger organizations that already have compliance product managers, Corsa makes that role significantly more powerful.

Rather than spending their time writing requirements, waiting for engineering capacity, maintaining integrations and rebuilding workflows, compliance product managers can directly own and evolve the compliance logic themselves — with little to no dependency on engineering.

And that's important because the work never stops.

A new geography shouldn't create months of engineering work. A new product shouldn't require rebuilding monitoring infrastructure. Changing a risk model, adding a rule or adjusting an onboarding flow shouldn't sit in an engineering backlog.

As the business evolves, Compliance should be able to evolve with it.

That's the shift I think is coming: from Compliance asking Engineering to build the logic, to Compliance actually owning it.