Two kinds of orchestration

"Orchestration" is now the most overloaded word in financial compliance. Every CLM platform claims it. Every KYC vendor claims it. We claim it too.

The word is doing two entirely different jobs, and the difference decides which product you should be buying.

Process orchestration moves a client through a journey. Onboarding → risk rating → approval → periodic review → offboarding. Cases, queues, four-eyes checks, an entity record that survives the client's whole lifecycle. This is what enterprise Client Lifecycle Management platforms do, and the good ones do it extremely well.

Vendor orchestration decides who actually performs the check. Which rail satisfies this obligation in this jurisdiction, at this risk tier, for this entity type — and what happens when that rail is down, degraded, or three times more expensive than the alternative that also satisfies the regulator.

"Process orchestration assumes verification is a black box that returns a result. Vendor orchestration is that black box. Opening it is the entire point of Omnified."

01 · What actually breaks when you cross a border

Every multi-market fintech we talk to describes the same four failures, in the same order.

• Fragmented vendors. Onfido in the UK, Persona in the US, IDfy in India, Sumsub in the EU. Different APIs, different document taxonomies, different result schemas, different confidence semantics. "Pass" does not mean the same thing in two of them.
• Divergent regulation. MAS, IFSCA, FCA, FinCEN, EU AMLR, the GCC regimes — each with its own CDD tiers, data-residency constraints, and audit expectations. The rules are knowable. Keeping them synchronized with what your code actually executes is where teams lose control.
• Slow, costly integration. Three to six months of engineering per country, and the work is not novel: the same waterfall logic, the same retry semantics, the same reconciliation layer, rebuilt per market by a team that would rather be shipping product.
• No cost optimization. Invisible on the balance sheet because it never shows up as a line item. Firms run full document-plus-biometric checks everywhere — including in markets where a government database lookup fully satisfies the regulator at a fraction of the price. You are not overpaying for compliance. You are overpaying for the wrong tier of evidence.

Notice what these four have in common. Not one of them is a workflow problem. A better case-management queue does not fix any of them.

02 · Rules tell you what. Rails tell you how.

Here is the distinction that took us longest to articulate, and it is the one we would ask a technical buyer to hold on to.

A mature regulatory rules engine encodes obligations. For a Singapore-incorporated corporate at standard risk, it knows which data points, which documents, and which ownership depth the regime requires. Serious incumbents maintain this content across 120-plus jurisdictions with staffed regulatory teams doing continuous horizon scanning. That work is real, it is expensive, and it is a genuine moat. We are not going to pretend otherwise, and a vendor who tells you the incumbents "don't have rules" is not being straight with you.

But an obligation is not an execution path.

Knowing that Singapore requires verified identity attributes is different from having a live Singpass/MyInfo connection that returns them. Knowing India permits a CKYC record lookup is different from being integrated with CKYC and DigiLocker. Rules content tells you the destination. Rails are the road. In practice, most platforms reach national identity rails through third-party IDV partners and generic integration hubs — which means the routing decision, the failover behaviour, and the unit economics all sit outside the product you bought.

Omnified encodes both halves. The rulebook resolves what the jurisdiction requires; the routing layer resolves which local rail satisfies it and sends the check there. Rules plus rails, as code.

03 · Inside the engine

Every verification passes through five stages. One call in; one normalized verdict out — verify_customer(customer, jurisdiction="auto", risk_tier="auto").

The economic consequence of stage 03 is the part worth dwelling on. When a cheap database lookup satisfies the regulator, you pay for a database lookup. When it doesn't, you escalate — and only then. That is not a discount. It is a structurally different cost curve, and it compounds with volume.

04 · Why we can be neutral, and incumbents structurally can't

We have no first-party verification product.

That single fact is the whole argument. A platform that sells its own document-and-biometric ID&V has a margin interest in which path your check takes. A platform with preferred data partners has a commercial interest in which provider gets configured on your tenant. Neither is a scandal — it is just how those businesses are built.

Omnified makes money on routed volume, not on being the vendor. Our incentive is to find you the cheapest compliant path, because the cheapest compliant path is what makes the routing layer worth paying for. Vendors are our suppliers, not our rivals: every partner in the catalog gains volume when routing sends traffic their way.

The commercial model follows from it. Per-verification usage on wholesale rates, plus a console subscription. No entity-volume bands. No four-year term. No contractual annual escalator. No implementation program that costs more than the licence.

"You can leave. That is the point of the word "neutral.""

05 · The agent question, stated precisely

AI agents are starting to run onboarding, remediation, and periodic review. They need compliance infrastructure they can call as a tool, with governance a regulator will accept.

The incumbents see this clearly and are building for it. Fenergo's Fen-AI and KYRA layer, launched in July 2026, uses Model Context Protocol and agent-to-agent interoperability to authenticate requests, preserve context across handoffs, and attribute completed actions inside an audit trail. It is real and it is shipping. Anyone telling you enterprise CLM has no agentic story is behind.

But read what it governs: access to that platform's own system of record, and handoffs between approved agents inside that estate. It is an inward-facing governance layer for one vendor's record.

Omnified's MCP server is the other shape entirely — an open, vendor-neutral verification API that any agent can call. verify_customer. check_sanctions. verify_document. Not a governed workforce bolted to one vendor's system of record, but a verification primitive that an agent built by anyone, on any framework, can invoke and get a normalized, auditable answer from.

Both are MCP. They are not the same product, and the difference is who the protocol is pointed at.

06 · What Omnified is not

We would rather lose a deal early than lose it in production.

We do not do transaction monitoring. We do not do bank-scale case management, multi-layer UBO unwrapping, ISDA and credit-document workflows, or entity system-of-record. We do not maintain rules content across 120-plus jurisdictions and will not claim to for years — we go corridor by corridor, deep rather than wide.

If you are a Tier-1 bank running a multi-year compliance transformation, you should buy an enterprise CLM platform. That market is well served by companies who have earned their position in it, and we are not going to waste your procurement team's time pretending otherwise.

Omnified sits underneath the compliance stack, not in place of it. If you already run a CLM platform, we are the layer that decides which rail executes the check it asks for. If you are a fintech or wealth platform sitting below the enterprise price floor, we are the layer that means you never had to build one.

"Vendors verify. Omnified orchestrates."

07 · Corridor by corridor

We launch where cross-border onboarding pain is sharpest, then follow the corridors our customers already serve.

Where we actually are, stated plainly: the MCP server and orchestration engine are running as a prototype today, with rulebooks drafted for Singapore (MAS 626) and GIFT City (IFSCA AML/CFT). v1 ships in those two corridors in Q3 2026 alongside sandbox entry. India domestic — DigiLocker, CKYC — follows in Q4. Hong Kong and UAE rulebooks in Q1 2027. Anything on this page not yet live is labelled as such, here and in our documentation, because a compliance vendor that fudges its own status has already told you how it will handle yours.

Start here

Read the API reference. Get a key. Run verify_customer against a Singapore or GIFT City test case and read the audit trail it produces. If the routing decision doesn't make sense to you, we have failed at the only thing we do.