The Yoti ID app stops being available in Spanish app stores today (Biometric Update). We wrote about why that happened yesterday: Spain’s data protection regulator read GDPR Article 9 as written, decided that matching a live selfie against a stored template counts as uniquely identifying a person, and Yoti concluded that the only fix a regulator would accept made the product weaker than not shipping it.
That post was about the law. This one is about the people who have to do something about it this week.
If you were a Spanish service using that app as one of your age assurance paths, none of the legal reasoning helps you. Your problem is smaller and much more urgent. A route your users depended on is gone, and the record of who already passed through it is not in your database.
That is the part almost nobody plans for. Everyone in this industry runs vendor evaluations. Very few run vendor exits.
A vendor can disappear four different ways, and only one of them looks like failure
The mental model most teams carry is that a supplier either works or goes bankrupt. Age assurance has a wider set of exits than that, and three of the four happen to companies that are doing fine.
Regulatory exit. A regulator in one country makes the product unshippable there, and the vendor leaves rather than build a country-specific variant. This is the Yoti case. The company is not in trouble. It has simply decided that one market is not worth a weaker product, which is a rational choice for them and a terrible surprise for you. Expect more of this as national rules diverge. Governments have converged on wanting age assurance and diverged sharply on how it must work (Biometric Update).
Enforcement failure. The vendor stays, but the method stops counting. Ofcom told services relying on age inference to move to methods listed in its guidance as highly effective, and to do it without delay. When a regulator reclassifies a technique, every service using it inherits a migration with no notice period. Ofcom and the ICO also made clear in their joint statement of 25 March 2026 that online safety and data protection duties are enforced together, and that “effective” is a performance bar rather than a checkbox (Covington).
Acquisition. The vendor is bought, and the roadmap, the price list and the sub-processor list all change under you. This is the most common exit by volume and the one people take least seriously. Entrust bought Onfido. Incode bought AuthenticID. LexisNexis Risk Solutions bought IDVerse. Socure paid 136 million dollars for Effectiv. Analysts expect the consolidation to keep running through 2026 (Biometric Update). Nobody sends you a breach notice when your vendor gets acquired. You find out when the renewal quote arrives.
Ordinary failure. Outage, breach, insolvency. We have written separately about what to do during an outage and about what a centralised architecture concentrates. An outage is a bad afternoon. Insolvency is the same problem as a regulatory exit, with less notice and a receiver in the middle who has no interest in your data export.
Only the fourth category looks like a supplier problem. The first three look like normal corporate life, which is exactly why they get left out of risk registers.
The integration is a week. The user base is a year.
Ask an engineering team what switching age assurance vendors would cost, and you will usually get an answer about the integration. Two endpoints, a webhook, a redirect, some tests. On a well-factored codebase that really is about a week.
That answer is wrong by roughly two orders of magnitude, because the integration is not the thing you bought.
What you bought is a population of users who have been through a check and do not have to go through it again. That state is an asset with a real balance sheet value: it is the reason your returning users see a fast path instead of a document upload, and the reason your conversion numbers survive contact with a regulator. On a standard age assurance contract, that asset sits in the vendor’s database.
Three specific things go missing when the vendor does.
The verified state of every returning user. If the vendor holds the mapping from your user to “checked, over 18, on this date, by this method”, then losing the vendor resets every one of those users to unknown. Not to their self-declared age. To unknown. A fresh self-declaration is not a check, so it cannot move an account back out of that group.
The evidence trail. Your regulator will ask what you had in place last March, not what you have in place today. If the answer lives in a dashboard you no longer have a login for, you have an evidence problem that no amount of new integration work fixes.
The reusable credential your users are holding. Reusable age credentials are the best idea in this industry and the worst lock-in in it, at the same time. A credential your users carry is only worth something while somebody is still willing to verify it. When the issuer leaves the country, the credential does not migrate to your new vendor. It just stops working, and your users experience that as your service breaking.
The re-verification bill, in actual money
Here is the calculation that turns a procurement conversation into a budget conversation.
Take a service with 500,000 verified users and a vendor that has just gone away. Every one of those users has to be re-established.
If you re-establish them with a full document verification, the check where a passport is scanned, text is read off it and a face is matched against the photo, you pay per event. On our Growth plan that is 0.20 EUR. Five hundred thousand of them is 100,000 EUR, spent to learn something you already knew last month.
If you can re-establish most of them with a Check instead, the cheap operation covering browser-based age signals, liveness, a returning-user lookup or a hand-off to a credential the user already holds, you pay 0.02 EUR on the same plan. Growth includes 30,000 Checks a month, so the first tranche is already paid for and the remaining 470,000 bill at 0.02 EUR. The same population is 9,400 EUR.
Same users, same outcome, a difference of just over 90,000 EUR. The list rates are ten times apart and the included allowance widens the gap a little further. That ratio is the whole migration strategy in one number.
And the direct cost is the smaller half. A document flow is the highest-friction thing you will ever put in front of a customer. Push 500,000 people through one and you will lose some of them, permanently, and the ones you lose are disproportionately the people for whom the document path is hardest: no passport, a name that does not match their account, a phone camera that cannot hold focus. We covered the mechanics of that loss in drop-off and the operational shape of a bulk re-check in back-book remediation. A migration is a back-book exercise you did not choose and did not schedule.
One more thing about the timing. A vendor exit does not arrive in a quiet quarter. It arrives because a regulator moved, which means every other service in your market is running the same migration in the same month, competing for the same replacement vendor’s onboarding capacity.
The evidence duty does not transfer with the contract
This is the part that catches compliance teams, and it is worth being precise about.
Under the UK Online Safety Act, what you owe is a written record of the methods your service uses and how it uses them, your risk assessment, your children’s access assessment, and an accurate and timely answer to any information notice Ofcom serves (Ofcom guidance on highly effective age assurance). None of those duties sit with your vendor. They sit with you, and they cover periods during which you were using a vendor you no longer have.
Failing to answer the question is its own offence with its own price. Ofcom fined 8579 LLC 1.35 million pounds for missing age checks and a separate 50,000 pounds purely for failing to respond to a statutory information request. Youngtek Solutions was fined 500,000 pounds for the checks and another 100,000 for the non-response, so a sixth of what it paid was for the silence rather than the failure (our write-up). As of its July report, Ofcom had opened 23 investigations into providers of 88 adult services and fined seven of them (Biometric Update).
Read those two numbers together. A sixth of a bill, for not being able to answer a question about your own system. If your only record of last year’s checks was a vendor dashboard, and that vendor left in September, you cannot answer.
Now notice the tension. GDPR Article 5(1)(e) says you cannot keep personal data longer than you need it, and 250,000 euros of the AEPD’s 950,000 euro fine against Yoti was for exactly that failure (ID Tech Wire). So “keep everything forever, just in case a regulator asks” is not available to you either.
The way out of that tension is the same design that solves the migration problem, which is a pleasant coincidence and the main point of this article. You do not need to keep the passport image to prove you did a check. You need to keep the decision.
What is portable, and what is not
Not everything in an age assurance system can move, and the useful skill is knowing which column each item is in before you sign rather than after.
| Artefact | Portable? | Why | What to do |
|---|---|---|---|
| Decision record (outcome, method, threshold, confidence, policy version, timestamp) | Yes | Small, structured, not special category data on its own | Store your own copy from day one. This is the one that matters. |
| Age band or threshold result (“over 18”, “16 to 17”) | Yes | A claim about a user, not biometric data | Keep it in your database, with the decision record it came from |
| Audit log of checks served | Usually, with notice | Vendor-held, exportable, but only while the contract lives | Contract a scheduled export, not an export “on request” |
| Face embedding or biometric template | No, and you do not want it | Special category data under GDPR Article 9, with the legal basis problem Yoti just demonstrated | Leave it with the vendor. Contract its deletion. Do not import it. |
| Document images | No, and you really do not want it | Highest-value breach target in your estate, with a retention clock on it | Confirm the vendor deletes them, in writing, with a maximum number of hours |
| Reusable credential the user holds | No | Bound to the issuer’s trust anchor, not to you | Assume it dies with the vendor. Plan a re-issue path. |
| Model, thresholds, accuracy characteristics | No | The vendor’s product | Anchor the requirement to a standard instead, so results are comparable |
That last row is why ISO/IEC 27566 matters more than it looks. You cannot port a vendor’s model. You can write your assurance requirement against a published standard, so that “what we required before” and “what we require now” are the same sentence with a different supplier’s name in it. Without a standard anchor, every migration reopens the question of what good enough means, and reopening that question in a hurry is how services end up accepting a weaker check than the one they had.
Six clauses to sign before you need them
None of these are exotic. All of them are much easier to get at signature than at renewal, and nearly impossible to get during an exit.
1. A scheduled export, in a named format. Not “the provider shall make data available on request”. A format, a field list, and a maximum number of days. Better still, a continuous feed: every decision your vendor makes lands in your own store as it happens, so there is no export to negotiate because you already have everything.
2. Records survive termination; raw data does not. These pull in opposite directions and both need writing down. You keep the decision records for as long as your regulator’s record-keeping duty runs. The vendor deletes the document images, the embeddings and the liveness video on a stated clock. Getting only the first half is a retention liability. Getting only the second half is an evidence gap.
3. Notice on any change of sub-processor or processing jurisdiction. Acquisition is the exit nobody plans for, and the first thing an acquirer does is move infrastructure. Your own data processing agreement commitments to your customers depend on a sub-processor list you do not control. Contract for notice with a right to object, not a notice for information only.
4. Certification lapse as a termination trigger. If the vendor’s method stops meeting the standard you bought it against, or a regulator reclassifies it, you get out without penalty. Without this clause you are paying for a method you are no longer allowed to rely on, until the term ends.
5. Migration support, priced at zero, defined in days. The moment you need it is the moment your commercial leverage is gone. Define it now: named contact, defined scope, a deadline.
6. No re-verification charge for a population you have already paid to verify. If you move to a vendor that can accept an existing decision record and confirm it cheaply, do not let the pricing model charge you full document rates to re-establish users you established last year.
Take one hour and check whether your current contract has any of the six. Most do not have three.
The architecture that makes a vendor replaceable
Strip the above down and there is a single design decision underneath it.
Hold the decision, not the document.
A decision record is small. Outcome, method, threshold, confidence, policy version, timestamp, and a reference you can trace. It is not a passport scan. It is not a face embedding. It is not special category data on its own, so it does not carry the Article 9 problem, and it is small enough that keeping it for the length of a record-keeping duty is not a retention risk.
That one record does four jobs at once:
- It answers the regulator’s question about what you had in place, and when, including for a vendor you no longer use.
- It tells your new vendor what has already been established, so a migration can run as a cheap confirmation instead of a full re-verification.
- It drives your re-verification cadence, because “when was this decided, by which method” is the input every expiry policy needs.
- It makes the vendor a supplier of a decision rather than the owner of your user base.
The alternative, and it is what most integrations actually do, is to store a boolean. age_verified: true. A boolean cannot answer any of the four. It cannot be evidenced, it cannot be migrated, and it cannot be aged. It is the single most expensive shortcut in this field, and it costs nothing to avoid on the day you write the integration.
If you take one thing from this article, take that. Add the columns now. The migration you are protecting yourself against may never happen, and the record-keeping duty is real regardless.
How Xident is built for this
Three parts of our design exist because of this problem, and one of them is a deliberate commercial choice rather than a technical one.
Decision records instead of retained documents. Every decision we return is stored as a record: outcome, method, threshold, confidence, policy version and timestamp. Not the passport image, which is deleted within 24 hours. That record is the portable artefact described above. It is what you evidence to a regulator, what you age against an expiry policy, and what a replacement provider can act on. We would rather you hold it than depend on us to hold it for you.
Two operations, priced about ten times apart, which is what makes a migration affordable. A Check covers browser-based age checks, liveness, returning-user Xident ID lookup and OAuth. A Verification is the document path with optical character recognition and a face match. On Growth those are 0.02 EUR and 0.20 EUR. A migration that can run mostly as Checks costs about a tenth of one that has to run as Verifications, and on the 500,000-user population above that difference is just over 90,000 EUR. That gap is the whole reason we split the two operations rather than charging one blended rate.
A sandbox sized for rehearsing the migration, not for a demo. The free tier grants 1,000 Checks and 100 document Verifications as one-time allowances, not a monthly quota. The Verifications exist so you can exercise the document path end to end, including the failure branches, before you pay for anything. A migration plan that has never been run against a real integration is not a plan, and this is the cheapest place to find out what breaks.
Our sub-processors and processing locations are listed in the data processing agreement rather than being something you have to ask for, which is the same principle applied to clause three above. You should be able to see what would change if we were acquired, without emailing anybody.
The short version
Everybody in age assurance runs a vendor evaluation. Almost nobody runs a vendor exit, and the exits are getting more common: a regulator can make a product unshippable in one country, a method can be reclassified without notice, and the acquisition wave has not finished.
The integration is a week of work. The verified state of your user base is a year of work and, at document rates on half a million users, 100,000 EUR to buy back something you already paid for once.
The fix is boring and it costs nothing today. Keep your own decision record for every check. Write the export and deletion clauses into the contract at signature, when you still have leverage. Anchor your assurance requirement to a published standard so a change of supplier is not also a change of policy.
Do that, and a vendor leaving is a procurement event. Skip it, and a vendor leaving is a re-verification programme with a regulator watching.
Xident provides age verification and age estimation infrastructure built around decision records rather than retained documents, with a cheap Check path and a separate document Verification path. The free sandbox includes a one-time allowance of 1,000 Checks and 100 document Verifications, which is enough to rehearse a migration before you commit to one. Talk to us about the exit clause your current contract is missing.
