If you chose your identity platform three or four years ago, you probably chose well. Different fraud environment, different regulatory perimeter, a different set of vendors on the shortlist. In a lot of cases the person who ran that evaluation has moved on, and the platform has just kept working, which is what good infrastructure is supposed to do.

Then somebody else’s roadmap decision arrives and becomes your project plan.

Identity orchestration is where that consolidation is landing. Products get absorbed into newer ones, roadmaps get rationalised, and customers get asked to reconfigure or re-integrate.

Worth saying plainly. They’re consolidating their platform. Not yours.

If that’s your situation, the business case you’ll be shown is built around the move itself: effort, timeline, cutover, and usually a waived implementation fee. Fine as far as it goes. It just doesn’t answer the only question that matters.

The pitch everyone makes

Every vendor in this category sells the same picture. One place for identity, fraud and compliance. One relationship. One view of the customer. It’s a good picture, and it’s what most teams want.

The appetite isn’t new, either. Back in 2020, Gartner’s Market Guide for Identity Proofing and Affirmation predicted that by 2023, 75 per cent of organisations would be using a single vendor with strong identity orchestration capabilities and connections to many other third parties for identity proofing and affirmation, up from fewer than 15 per cent at the time. Five years on, that appetite is a large part of why so much got packaged together so fast.

Because a lot of what buyers ended up with was point solutions in a bundle. Separate products, sold together, sharing a brand and an invoice and not a great deal else. Separate data models underneath. Often separate contracts, separate systems, separate logins.

Both get sold as all-in-one. The difference is whether the parts are connected, or just collected.

Collected means the products sit side by side. Each one works, each one returns a result, and turning those results into a decision is your team’s job.

Connected means a signal raised in one place changes what happens in another without anyone carrying it across. A fraud signal at onboarding informs the KYC risk decision. An AML screening match triggers enhanced due diligence inside the workflow. Transaction monitoring alerts feed back into the entity’s risk profile.

That distinction doesn’t show up on a feature list. Both versions tick the same boxes. It shows up in how much work lands on your people, and it stays invisible until you try to grow.

What identity orchestration actually means

Identity orchestration is a single connection that routes each check to the right data source and passes signals between check types, so identity verification, KYC, KYB, AML, fraud and transaction monitoring operate as one system rather than as separate tools. Adding a check, a data source or a market is a configuration change on the connection you already have, rather than a new integration.

That’s the promise. What gets sold under the label is frequently something else.

And the label won’t help you tell them apart. Everyone in this market calls themselves a platform. So do we. The word stopped filtering anything years ago, which leaves behaviour as the only thing worth testing.

You’re reconfiguring either way

Start with the concession, because leaving it out would be a bit rich in a piece about vendors overstating things.

The platform you’re being asked to move to is probably better than the one you’re leaving. It’s newer. It was built with better tooling, a clearer view of the current threat environment, and the benefit of watching the first generation make mistakes. If someone demos it against a product architected in 2019, that demo is going to go well.

That still isn’t the question.

The work is happening regardless. Your team is going to re-integrate, re-test, re-paper and re-certify something that already worked, and not one hour of it shows up as a feature your customers will ever notice. It’s pure cost, and you didn’t choose it.

So the only question worth the meeting is whether you’re doing it once.

Growth is where the difference shows up

None of this shows on day one. Any vendor can get a single check working, the demo will be fine, and the first integration will go roughly to plan.

It shows the first time you try to do something ordinary.

You open a new market. The coverage map says the country is covered, and it is, but the sources for it sit inside a different product. So before you verify a single customer there, you’re in a commercial conversation, then an order form, then legal, then a security review, then a build. Weeks of procurement to switch on a check the coverage map said you already had.

You start onboarding businesses as well as individuals. KYC was one product. KYB is another, with its own contract, its own system and its own case file. So when a director throws a fraud signal, ask what happens to the business assessment, and ask to be shown it rather than told. If the answer involves two logins or an export, your operations team is the path between them, manually, on every file, forever.

You add monitoring after onboarding. Onboarding is where identity gets sold. Ongoing monitoring, reverification and transaction screening are usually priced and built separately, and they are where the real cost sits across a customer’s life.

A data source gets retired. Providers get acquired, deprecated and repriced constantly. Somebody absorbs that work. In a bundle it lands in your engineering backlog, competing with everything your customers actually asked for.

The pattern is the same every time. With point solutions, growth is a procurement event. The alternative is that growth is a settings change: same connection, same contract, same data model, different configuration.

So the question to put in front of your account manager is short, and it isn’t about features. When I open my next market, add my next product, or move a check from onboarding into ongoing monitoring, am I configuring something, or am I signing something?

Ask it about each of these, and listen for which column the answer falls into.

The question a feature list can’t answer

One more, and it gets skipped because it isn’t on anyone’s comparison grid.

Your pass rate isn’t determined by the workflow builder or the dashboard. It’s determined by which data sources sit behind them, market by market. So ask for that list source by source, mapped against what you use today, in every country you operate in and the ones you’re heading into. In Australia that means naming them out loud: the Document Verification Service, face to face verification through Australia Post, credit header data, tenancy, superannuation and payroll, death check. Then ask the harder follow-up. What happens to the ones that aren’t on the list?

This matters more than it sounds, because a missing source doesn’t fail loudly. Nothing breaks. There’s no alert. It shows up as a slightly lower first-pass rate, spread thinly across every application you take, and it looks like ordinary variance for months.

So do the arithmetic before you commit rather than after. Take your annual application volume, drop your first-pass rate by two percentage points, and price both halves of what that costs: the applications that need manual handling, and the ones that quietly go away. Then hold that against the migration budget you’ve been quoted. Whatever the comparison tells you, remember which one repeats. The migration happens once. The pass rate is every year.

The line item that never makes the business case

This is the part compliance raises late, usually once the timeline has already been agreed.

Your AML/CTF program documents the verification methods you actually use. Change the methods and the program needs updating and re-approving on your governance calendar, not the vendor’s. That calendar is rarely as accommodating as a cutover date.

Then there’s the window. Between switching off the old checks and going live on the new ones, you need to know precisely how you’re covered, who decided that, and where it is written down.

And there’s equivalence. Somebody has to sign off that the new checks do the same job as the old ones. Ask early what that assessment examines, because "same vendor category" and "same data sources, market by market" are very different standards, and only one of them protects your pass rate.

None of this is exotic. It sits outside the migration business case because the migration business case is written by the party doing the migrating.

Where we sit

FrankieOne is a unified platform for global identity, fraud and compliance orchestration, connecting to 350+ best-in-class KYC, KYB, AML and fraud providers through a single integration, across 195+ countries, covering onboarding, ongoing due diligence and re-verification. That is the whole description, and it is easy to claim. Every vendor in this category claims some version of it.

So run the questions above on us the same way you’d run them on anyone else, and ask for evidence rather than taking the sentence on trust. Here is ours.

What consolidating changed for three customers

All figures below are reported by the customers, not by us.

Lumi, an Australian business lender, had KYC and KYB checks spread across multiple providers, with customer and business data sitting in disconnected systems. Manual data entry was the backbone of onboarding, and checks failed often enough on formatting rather than genuine risk that rework became a standing cost. They also wanted biometric verification, which nobody in business lending was doing at the time. All of it landed on one connection. Automating the primary checks moved the team off blanket manual validation and onto exception-based review. Within the first 90 days, Lumi identified and prevented approximately $400,000 in potential fraud losses, and reported $45,000 or more in annual operational savings.

Pay.com.au had the more familiar problem: a compliance stack spread across several providers, with identity verification in one system, business verification in another, and watchlist screening with limited coverage. The tools worked. The joins between them didn't, so the operations team spent its days manually validating verification data, edge case by edge case.

What moved them wasn't performance. It was where they were headed. Pay.com.au wanted an architecture that carried multi-jurisdictional requirements without an engineering project attached to each one, which is the growth test in this article applied before the growth rather than after it. Yvonne Gilmour, Head of Operations at Pay.com.au, puts it plainly: "We wanted a platform that could scale globally with us, not just solve for Australian compliance. FrankieOne gave us that flexibility through a single integration, with the ability to switch providers and plug in new solutions as we expand into new markets."

After consolidating onto a single connection, Pay.com.au reported a 25 per cent uplift in pass rates, a reduction in manual reviews of approximately 40 per cent, and standard application processing compressed from two or three days to under 24 hours. They also absorbed significant volume growth without adding headcount to the compliance function, which is the cost that never shows up in a licence fee comparison.

Westpac is the version that runs long, and it is the one to look at if you are reading this from inside a bank. They went live in 2020 on individual verification. The part worth noticing isn’t the go-live. It’s what came after. Their Principal Product Owner for Westpac Digital describes continuing to deploy FrankieOne across the broader group, and singles out how the rollout went when adding new business units. That is the test in this article, run over five years inside a major bank. New units, same connection.

Three different problems. One shared property: the checks share a connection, which is the part a feature comparison can’t show you.

Why this is the only cheap moment

Here is the one useful thing about a migration you didn’t choose.

Nobody re-opens infrastructure that works. They shouldn’t, either. Re-running an evaluation on a platform that is quietly doing its job is a poor use of a quarter, and the cost of switching is usually enough to end the conversation before it starts.

A move you didn’t choose removes that. The moment you’re re-integrating anyway, staying costs roughly what leaving costs, and the decision is open in a way it hasn’t been since the last time you ran a process.

That window closes when the cutover date gets signed. So use it while it is open.

What to ask before you commit

Ask for these in writing. A verbal yes in a roadmap conversation is not a commitment you can hold anyone to.

Start with three, because they do most of the work.

When you open your next market, is that a configuration change, or a new contract and a new integration? Same question for your next product. And if you verify a company and its directors, is that one product or two?

If all three answers are "configuration", the rest of the conversation gets much easier. If any of them is "new contract", you are looking at point solutions in a bundle, and it is better to know that before you sign than in month three.

From there it gets more specific. Source-by-source coverage against what you run today, in every market you operate in and the ones you are heading into. Who absorbs the work when a source is retired or repriced. What is contractually committed about the roadmap you are being moved to. Whether both providers can run in parallel on live traffic while you compare outcomes. And who signs off that the new checks are equivalent to the old ones.

We’ve turned these into a checklist you can take into the meeting, with what to listen for in each answer, a coverage grid to fill in, and a way to score what you hear. It works against any vendor, including us.

→Get the vendor evaluation checklist

The answer you’ll be asked for later

Strip out the vendor argument and one thing is left that belongs to you rather than to procurement.

At some point after this is done, somebody asks why the verification methods changed, what was checked before they did, and who decided the new ones were equivalent. An auditor. A regulator. Your own board, two years from now, after something has gone wrong for an entirely unrelated reason.

That answer gets written now or it doesn’t get written at all. Nobody reconstructs it afterwards from a cutover plan and a vendor deck.

You don’t own the decision to migrate. You own the record of how it was made. Whether the platform you land on turns identity orchestration into one connection or six will shape that record for years, which makes it worth an afternoon of questions now.

Questions we get asked

What is identity orchestration?

Identity orchestration is a single connection that routes verification checks across multiple data sources and passes signals between them, so identity verification, KYC, KYB, AML, fraud and transaction monitoring run as one system rather than as separate tools. Adding a check, a source or a market is a configuration change rather than a new integration project.

What should you ask before migrating identity verification providers?

Ask whether growth costs a configuration change or a new agreement: what happens when you open a new market, switch on another product, or move a check from onboarding into ongoing monitoring. Then ask for a source-by-source comparison of data coverage against what you run today, whether both providers can run in parallel on live traffic, and for roadmap commitments in writing. The full list of ten is above.

What happens to pass rates when you change identity verification providers?

Pass rates depend on which data sources sit behind the platform, so any gap in source coverage between the old provider and the new one tends to show up as a lower first-pass rate. It rarely fails visibly. It appears as a small decline spread across every application, which is why a parallel run on live traffic is worth doing before cutover.

How many integrations should identity verification require?

One. If adding a check type, a data source, a product or a market requires a second integration, the work of orchestration has been moved to your team rather than absorbed by the vendor. A useful test before signing: ask whether your next market or your next product is a configuration change or a new contract.