By Maryna Poplavska, Head of Project Managers, Trembit — delivery of real-time video products and the trust layers around them · Last updated 29 October 2026
Someone forwards you a compliance note, and suddenly your signup flow is a regulatory question. Age assurance — establishing that a user is an adult before letting them in, either by verifying it (commonly against a document) or estimating it from a signal such as a face — is now a design constraint for anything with UK users and grown-up content. The surprise is where the work actually sits (ours). On the one integration we can speak for, wiring up the check was a couple of days. Deciding which duty you are under takes longer, because the UK Online Safety Act contains two of them, they demand different things, and one has an exception that is easy to miss. Get that wrong and you either build a check you did not owe, or you skip one you did.
If you own compliance rather than the codebase, start at Which duty are you under — it is self-contained — then come back for what you have to be able to show and the six things to do now. Otherwise the engineering reality comes first, then the clause that decides it.
Key takeaways
- The check itself is the cheap part. On the platform behind this guide the UK age step — integration, the regional branch, corner cases — came to roughly two days. The states, the evidence rule and whatever appeal route you choose are where we would expect the time to go — our reading, not a figure from that project.
Two duties, not one — and a service can owe both. Part 5 (s.80–81) bites on content the provider publishes — regulated provider pornographic content — and Part 3 (s.12) on the primary priority content users share. The split attaches to the content, not the service, so a platform carrying both owes both. Part 5’s age-check duty carries no equivalent to the exception Part 3 provides at s.12(5).
The exception that is easy to miss: s.12(4)’s requirement — which bites on primary priority content the provider identifies — applies in every case except where your terms prohibit that kind of content and the policy applies to all users (s.12(5)).
- “Highly effective” is an outcome test, not a product list. Where a check is required, the Act asks for one “highly effective at correctly determining whether or not a particular user is a child” — and the words “used in such a way” put your implementation inside the test.
- Record and statement are not the same document. Part 5 makes you keep a record (s.81(4)) and publish a statement (s.81(5)). Reading the published statement as the narrower of the two is ours; both provisions are framed against the same duty.
This is an engineering guide, not legal advice. It quotes the Act so you can check it yourself, and it stops where our competence stops: you will not find a claim here that a given method or vendor satisfies the regulator, because that judgement belongs to your counsel and, in enforcement, to Ofcom, not to the team building the onboarding screen. That omission is deliberate — treat any article that does make the claim with more suspicion, not less.
What does age assurance actually change in your product?
The check itself is small
You might expect this to be the hard part. On the one build we can speak for it was not. On the platform behind this guide — a video-first dating product scoped to meet the UK rule — integrating the age check, adding the regional branch and handling the corner cases came to roughly two days of engineering. That is one integration, not a survey of the category (ours).
The design around it is not
What costs you is everything the check implies. A verification outcome is a new state on the account, which means new transitions, new failure modes and a new question on every screen that assumed a user was simply “signed up”. If you offer an appeal it needs a queue a human actually works — and deciding not to offer one — as this build did on its member gate — is itself the decision. Evidence needs a retention rule settled before the first dispute, not after. And the whole thing has to be re-runnable, because methods get replaced and obligations change.
It also moves where your funnel bleeds. An age check sits between a stranger and a product they have not yet seen the value of, so instrument abandonment at that step with the same care you give the check’s accuracy. It is the number your growth team will ask about first.
Which duty are you under, and does it actually require a check?
Everything downstream depends on this, and the question is not only what kind of service you run: it is who publishes the content the rules are worried about. The split attaches to the content (s.79(2), s.79(7)), and s.80(3)(a) takes for granted that a user-to-user service can fall inside Part 5 — so one service can owe both duties at once, on different content.
Part 5 — the service publishes it
Part 5 bites where regulated provider pornographic content is published or displayed on the service, the service is not exempt, and it has links with the UK (s.80(2)). Once you are inside that scope the duty carries no further condition: use age verification or age estimation so that children are “not normally able to encounter” that content (s.81(2)). The section provides no equivalent to the s.12(5) exception discussed below. Both Parts carry record-keeping duties — s.23 requires a Part 3 provider to keep a written record of every risk assessment; of any measures taken or in use that a code of practice describes and recommends; and, where alternative measures are used instead, of how those amount to compliance and how s.49(5) was met. s.23(6) adds a duty to review compliance regularly and as soon as reasonably practicable after any significant change to the design or operation of the service. s.81 carries the Part 5 record duty, though no review duty to match s.23(6). What differs is the shape of the record, not whether there is one.
Part 3 — your users publish it
Section 12 applies to regulated user-to-user services likely to be accessed by children — and that phrase is a defined term, with its own machinery. Section 36 requires you to carry out a children’s access assessment, the first at a time set by Schedule 3, and then at least yearly for as long as the service is not already treated as likely to be accessed by children. Section 35 says what it asks: can children access the service, and is the child user condition met — a significant number of children among the users, or a service of a kind likely to attract a significant number of them. On the significant-number limb, s.35(4)(b) says the test is evidence about who actually uses a service, rather than who the intended users are. Under s.35(2) you may conclude children cannot access it only where age verification or estimation is already in use to that effect. And s.37 is the sharp end for an adults-only product: ordinarily it is your own assessment that puts you in scope — but if you never carry the first one out, s.37(4)–(5) treats the service as likely to be accessed by children from the date it was due, until you do, and s.37(6)–(7) lets Ofcom determine the same thing after investigating a failure to comply with s.36. Not assessing is not a way out; it is the way in. The core duty is to run systems that prevent children of any age from encountering primary priority content — a defined term (s.61) covering pornographic content and also content which encourages, promotes or provides instructions for suicide, deliberate self-injury or an eating disorder — and the duty works kind by kind rather than all at once. Where a provider identifies such content on the service, s.12(4) requires age verification or estimation.
Where the content is user-generated rather than published by the service, this is the part to read first. It is easy to assume the opposite from the subject matter and design to the other duty — which is why the classification is worth settling with a lawyer before anything is built.
The exception at s.12(5), which is easy to miss
The s.12(4) requirement applies in every case except where two things are both true: your terms of service indicate that the presence of that kind of content is prohibited, and that policy applies to all users of the service.
A product that bans the content outright is in a different position from one that hosts it. That does not make s.12 disappear — the duty to run proportionate systems, and the risk assessment behind it, still apply — but it is the difference between you must deploy age checks and you must show your systems work. If you are about to fund an age-assurance project, this is the clause to put in front of your lawyer first.
One contrast worth carrying into the meeting
The two parts do not even ask for the same outcome. Part 3 speaks of preventing children from encountering the content. Part 5 asks that they be “not normally able to encounter” it. The Part 5 wording sounds softer while its duty carries no further condition once you are in scope; the Part 3 wording sounds absolute while its age-check requirement is conditional. Read the words, not the summaries. Section 12 came into force on 10 January 2024 and section 81 on 17 January 2025; when a duty starts being enforced against a particular service is a separate question from when the section commenced.
What does “highly effective” mean once you have to implement it?
Where a check is required, both Parts use the same words: the age verification or estimation must be of such a kind, and used in such a way, that it is “highly effective at correctly determining whether or not a particular user is a child” (s.12(6), and s.81(3) for Part 5). Note the condition on the Part 3 side: s.12(6) attaches only if a provider is required by s.12(4). Inside the s.12(5) exception it does not, and s.12(7) treats a check run there as one optional measure among others.
It is a test of outcome, not a list of approved products
The Act names no technologies, and no method or vendor is compliant by virtue of being that method or vendor. What the Act does do is oblige Ofcom, at s.82, to publish guidance giving examples of kinds and uses of age verification and age estimation that are, and are not, highly effective at correctly determining whether a user is a child. Note who it is for: s.82(1) addresses it to providers within s.80(2) and their s.81 duties — Part 5. If you are under Part 3, s.82 does not address its guidance to you — ask your counsel what the regulator has published for Part 3 services instead. Either way, read it rather than a vendor’s claim. Anyone selling you certainty on this point is selling you their own opinion.
“Used in such a way” puts your implementation inside the test
This is the clause engineers should read twice, because it puts deployment inside the test. Our reading of what that implies, and it is only ours: a strong method behind a screen a user can skip is not doing the work the method claims; nor is one that accepts a replayed capture, or one a user can retry until it passes. The Act names none of those cases, and which methods and uses fall short is what s.82 has Ofcom publish examples of, for Part 5 providers — so test your deployment, do not take our list as the test.
In practice you are being asked a binary rather than an age (ours)
What the duty turns on is child or not child. Note that the Act is drawn more widely than that: s.230(2) defines age verification as a measure designed to verify a user’s exact age, and s.230(3) age estimation as one designed to estimate an age or age-range. So the binary is the shape of the decision you have to make, not a limit on what the Act contemplates measuring (ours). It is still a lower bar than identity, and designing to the question you were actually asked keeps you from collecting data you then have to protect.
Which method should you reach for, and what does each cost you?
Treat these as engineering trade-offs. Which is sufficient in your circumstances is a question for your lawyers. Age assurance is also only one control in a trust layer that has to work as a whole — the content moderation pipeline beside it carries its own human-review and evidence decisions, and the same people usually build both.
Document plus a live selfie
The user photographs an identity document, then a live capture is matched against it. Depending on the implementation and on what you retain, this can give a stronger evidentiary trail than the alternatives — at a heavier cost to the user, since you are asking for a passport from someone who has not yet seen the product. Liveness is the fragile part: a photograph of a photograph defeats a naive implementation, which is its own subject in why most liveness-detection systems fail on dating apps.
Facial age estimation
A model estimates an age band from a selfie, no document involved. Far lower friction and nothing documentary to store — at the cost of a confidence band rather than a fact, and accuracy you should test across your own user population before you trust it — a fairness problem before it is a compliance one (ours).
Payment and account-based signals
A card check, or an attestation from a bank or mobile operator. Frictionless for users who have the instrument and useless for those who do not, and each one adds a third-party dependency to the single flow you least want flaky.
Self-declaration
A date-of-birth field, without more, is neither age verification nor age estimation under this framework. It is a terms-of-service artefact.
The two rules that cut across all of them
Store the verdict, not the evidence, wherever the method allows — what you keep is what you have to protect. And make the check re-runnable: people appeal, methods get replaced, and a design that treats verification as a one-off event rather than a state you can re-evaluate will fight you inside a year.
How do you scope a check to one market without forking onboarding?
This is the part that is pure engineering, and the part we most often see hard-coded (ours).
One flow with a branch, never two flows
The platform behind this guide puts the age check behind a condition rather than a fork: UK users pass it at sign-up, and the same flow does not impose it on markets that do not require it. (That is the sign-up check; whether the payout-side check is gated the same way is not something we can state.) One onboarding path with a conditional step — the moment you maintain a separate “UK version” you have two sets of bugs and one of them is always behind.
Region is decided server-side
Anything a client can assert, a client can lie about. The decision belongs where the audit trail is.
Verification is account state, not a screen
Store what was checked, by which method, and when. Then a new market, a new obligation, or a re-check of existing users is a change to a rule rather than a migration.
The pattern to avoid is a signup flow that knows only one country’s rules. That cost is not paid when you make the choice — it is paid the day someone asks how fast you can open a second market, and the honest answer is that onboarding has to be reopened rather than extended. A product already live in one market is the hardest place to add the branch, which is why dating app development is cheaper to scope for it up front (ours).
Why the people you pay need a different check
If your product pays anyone — creators, hosts, sellers — their check answers a different question and should not be collapsed into the first one.
Access asks is this person an adult. Payouts ask is this person who they claim to be, and may we pay them — a different question, and one that paying anybody raises rather than one the Online Safety Act raises (ours). They also run on different clocks: the access check has to be instant or it costs you a signup, while the payout check can take hours because no money is moving yet. In practice that means separate state machines, separate retention, and a rule that money cannot leave until the payout-side check clears.
What do you have to be able to show?
The documentation duties are easy to miss because they are not about technology at all.
Part 5: a record, and a public statement drawn from it
Section 81(4) requires a written record — in an easily understandable form — of the kinds of check used and how they are used, and of how you had regard to protecting UK users’ privacy when choosing them. Section 81(5) then requires a publicly available statement summarising that record so far as it concerns compliance with the age-check duty, including which kinds of check you use and how.
Reading the published statement as the narrower of the two is ours — s.81(4) and (5) are both framed against the same duty. On that reading the privacy reasoning sits in the record you keep; the statement you publish is scoped to the compliance side.
Part 3: the terms of service carry the duty
Section 12(9) requires your terms to specify how children are to be prevented from encountering the content in question, s.12(10) requires you to apply those provisions consistently, and s.12(11) adds that if you block access below a certain age, the terms must describe how that works.
The engineering consequence is the same either way: whatever you build has to be describable and consistent. A check that behaves differently for different users without a rule you can state is a problem before anyone asks whether it is effective.
What does this actually cost to build?
The integration is the small half
Two days on the platform behind this guide — one project’s number, not a benchmark. We are not publishing what the vendor cost, and we have not surveyed the category’s pricing, so take neither the days nor the licence as the place the surprises come from. They come from the design around the check.
The layer around it is the real scope
The account states and their transitions. The evidence trail and the retention rule behind it. Whatever you decide about appeals — including deciding against one. The re-verification design that lets you change method or market without a migration. None of that appears on a feature list, and each one is a decision somebody has to take rather than a line somebody forgets.
What we are not going to guess
How long that layer takes for you, because the honest answer depends on decisions you have not made yet: how many markets you will operate in, how generous your appeal policy is, and how long you must retain evidence. What we can say is its shape — it is a workstream with its own states, and whatever queue your appeal policy implies, rather than a ticket. Size it as one, and the check itself stops being the interesting part of the estimate.
What should you actually do if you are adding age assurance now?
Settle which duty applies before you shortlist a vendor. Take s.12(5) to your lawyer with your actual terms of service in hand. The answer changes the size of the project.
Design the account state first, the integration second. The states, transitions and evidence model outlive whichever vendor you pick.
Make region a server-side decision from day one, even if you only operate in one market today.
Write the record as you build, not afterwards. It is a duty under both Parts — s.81 for Part 5, s.23 for Part 3, which wants a written record of every risk assessment, of the code-of-practice measures taken or in use, and of any alternative measures and why they amount to compliance. Under Part 3, s.12(9)–(11) also require your terms to describe that behaviour.
Instrument drop-off at the check before you tune anything else about it.
- Keep the payout-side identity check separate, with its own states and its own clock.
FAQ
What is age assurance, and how is it different from age verification? Age assurance is the umbrella term. Age verification is a measure designed to establish a user’s exact age — commonly against a document, though the Act names no method; age estimation infers an age or age-range from a signal such as a face. The Act refers to both and, where a check is required, sets one standard for either: it must be highly effective at correctly determining whether a user is a child.
Does the Online Safety Act require every dating app to run age checks? No — it depends which duty applies to the content, and a service can be inside both on different content. Where the service itself publishes regulated provider pornographic content, is not exempt and has UK links, Part 5 applies and carries no further condition once in scope. Where users publish content — which by definition is not provider pornographic content — s.12 applies if the service is likely to be accessed by children, a test the provider applies in its own children’s access assessment (s.36, s.37), with evidence of who actually uses the service deciding the significant-number limb (s.35(4)(b)). The s.12(4) requirement then bites on primary priority content the provider identifies — pornography, and content encouraging suicide, self-injury or an eating disorder — with an explicit exception where the terms prohibit that kind of content for all users. Which of these describes which part of your product is a question to settle before you choose a vendor.
Is a date-of-birth field enough? No. Self-declaration is not, without more, age verification or age estimation — s.230(4) says so in terms; it is a terms-of-service record.
How long does it take to build? On the platform behind this guide the integration itself was roughly two days — one data point rather than an estimate for your build. The states, the evidence rule, whatever appeal route you choose and the re-verification design around it are the real scope, and they are what you should be estimating.
Do the people we pay need the same check as the people who sign up? They need a different one. Access asks whether someone is an adult; paying someone asks who they are — a question that paying anybody raises rather than one the Online Safety Act raises (ours). Keep them as separate states.
Talk to a team that has built this
If you are designing age assurance into a live product — where the check sits in onboarding, how to scope it to one market, how to keep the payout side separate — our engineers will spend thirty minutes on it with you. Knowing the rules is your lawyer’s job; knowing which of them turn into schema, state machines and account states is ours. That is the part we have actually done — the region-aware age step in onboarding described here, and before it an earlier geosocial video dating platform where moderation, verification and reporting were designed in from the start rather than bolted on. No charge and no deck, and we will tell you where the engineering ends and your lawyers begin. Tell us what you are building.
