Age-band compliance SDK for UK social and AI companion apps to enforce under-16 bans and teen feature limits without storing IDs.

1. The government is formally announcing the policy on June 15 and giving platforms a transition compliance window, so engineering and legal work starts now rather than after final standards land.
2. The UK is broadening the rule set from pure access control to late-night scrolling and romantic AI restrictions, which creates budget for a feature-policy layer instead of a single signup check.
3. Because facial scans, government ID, and banking data are all under consideration, platforms need a method-agnostic control plane before they know which proof type will survive.
4. A 9-in-10 parent support rate makes the mandate politically durable enough that mid-market apps cannot assume it will fade before enforcement.

Catalyst. Starmer's June 15 announcement and the promised transition window force product teams to ship auditable under-16 and under-18 controls before the UK has even finalized one verification method.

Teen Access Policy Engine is an SDK, rules engine, and audit console for consumer apps that need age-banded experiences. The product accepts multiple verification inputs already under government discussion—facial age estimation, government ID checks, banking-age signals, and manual review—and stores only the minimum policy output: age band, confidence, jurisdiction, and consent state. Product teams attach the SDK to signup, messaging, feed ranking, notification schedules, and AI persona endpoints; the engine returns whether a flow is allowed, blocked, or requires a stricter check. Counsel and trust-and-safety teams get a policy log showing which rule version fired, which evidence supported the decision, and where uncertain users were escalated. That turns a messy one-off compliance sprint into a reusable safety layer that can absorb future UK, Australian, and EU rule changes.

What's different. Existing age-check vendors mostly optimize for proof at signup, while generic feature-flag systems do not understand youth policy, evidence quality, or auditability. This startup owns the layer between any age-proof source and every risky product surface, so the customer can minimize retained PII while still showing why a decision was made. Its moat compounds through a jurisdiction-specific rules library and deep integrations across feeds, chat, notifications, and AI persona workflows.

Jobs to be done

flowchart LR
  Buyer[Trust and Safety Lead] --> Pain[Need to enforce under-16 and teen feature rules fast]
  Pain --> Product[Teen Access Policy Engine]
  Product --> Outcome[Keep UK product live with auditable low-PII compliance]

Executive takeaways

• The scarce layer is not age proof itself; it is feature-level policy orchestration across chat, feeds, notifications, and AI flows.
• Regulatory momentum is broad enough that a UK-first product can plausibly expand into EU and Australia without changing its core architecture.
• Proof vendors and device platforms will keep commoditizing the front door, so defensibility must come from rules, integrations, appeals, and audit evidence.
• The best early customers are apps that cannot afford to geoblock minors because youth engagement is core to retention, creator liquidity, or AI engagement.

Market definition

The relevant market is age-assurance-adjacent infrastructure for consumer platforms: software that converts age signals into jurisdiction-specific access, feature, and audit decisions.

Customer and buyer

The practical customer is the executive who owns trust, safety, product risk, or counsel for a consumer app whose teen traffic matters and whose legal team is too small to keep rebuilding age policy in-house.

Buying triggers

• General counsel or product leadership needs a shipped UK plan once child-safety duties move from abstract law to operational deadlines and product changes. [1][4][5]
• A privacy or regulator review exposes self-declaration as insufficient, pushing teams to add stronger proof, records, and correction flows. [12][14][18][19][21]
• Launching teen-facing chat, live, recommendation, or AI features creates a surface area that point verification vendors do not fully manage. [44][45][46][47]

Willingness to pay

Public proof pricing already creates a visible budget floor: OneID exposes age-verification rates from £15.65/month at 50 checks to £2,720/month at 10,000 checks, while public k-ID coverage shows buyers already expect usage-scaled compliance tooling. For a 1M-MAU class app with meaningful UK exposure, proof costs alone can reach the tens of thousands annually, leaving room for a separate orchestration layer. [58][83]

Category dynamics

Growth signal 14.7% CAGR

Validation signals

• ICO has already fined Reddit for failing to apply robust age assurance and for relying on self-declaration.
• ICO also fined Imgur owner MediaLab for having no age checks and no lawful basis for children’s data.
• Wizz’s layered self-declare + facial estimation + fallback flow shows a teen social app already buying multi-method age banding.
• Meta, TikTok, and Apple now treat teen protections as built-in product behavior, not just signup checks.
• Common Sense reports teens already use AI companions for serious conversations, making this beachhead more immediate than generic social.

Regulatory & technical constraints

• A service can only claim children cannot access it if age verification or age estimation normally keeps children out.
• Highly effective age assurance is required for primary priority content and provider-pornography duties.
• Incorrect age assessments require accessible complaint and correction flows.
• Safety measures must also account for privacy and expression impacts.
• Device- and wallet-based proofs increasingly expect minimal-disclosure credentials instead of raw ID retention.

The market is crowded at proof collection but thinner at orchestration. Vendors can verify or estimate age, device and app-store layers can surface age categories, and the largest platforms have internal teen-control stacks. The gap is a neutral control plane that takes any age signal and turns it into auditable, service-specific decisions across messaging, feeds, live features, notifications, and AI interactions.

Why incumbents do not win by default

• App stores and wallets. Apple and Google can centralize age categories or proof exchange, but they do not translate those signals into service-specific rules, complaint handling, or regulator-ready logs inside third-party apps.
• Age proof vendors. Yoti, VerifyMy, OneID, and similar vendors solve proof collection well, but customers still need to map age outputs to DM, feed, livestream, AI, and parental-consent policies.
• Platform-native trust stacks. Meta and TikTok demonstrate that real safety work happens across messaging, Live, feeds, notifications, and underage detection, but those systems are not productized for independent apps.
• In-house flags and counsel. Manual flags and legal memos may cover a single deadline, but the statutory mix of child safety, complaints, privacy, and recordkeeping creates an ongoing operating burden for mid-market teams.

Teen Access Policy Engine should start as the compliance control plane for UK-facing AI companion, fandom-chat, creator-community, and mid-market social apps whose teen traffic matters and whose product surface now extends beyond a signup age gate. The immediate pain is operational, not theoretical; after the June 15 UK announcement, buyers need to decide whether under-16 users can sign up, message, scroll late at night, or access romantic AI features, and they need an audit trail that counsel can defend. The product should sit above age-proof vendors and device signals, normalize selfie-age, bank-age, ID, or wallet signals into an age-band decision, and then enforce that decision across signup, DM, feeds, notifications, and AI endpoints while minimizing retained PII. The first customer should be a venture-backed app with 500,000 to 5 million MAUs, meaningful UK traffic, small legal and trust-and-safety teams, and revenue exposure if it geoblocks minors or overblocks borderline users. Pricing should start as a paid pilot plus annual SaaS priced by protected UK/EU MAUs and policy decision volume, because the buyer is funding a shipped compliance launch rather than a standalone identity product. The strategic wedge is narrow on purpose; win the UK launch on the riskiest surfaces first, then expand within account to more surfaces and across jurisdictions once the policy engine and audit evidence become embedded. Research supports the urgency and the orchestration gap, but two assumptions still need proof; mid-market apps must pay a separate low-six- figure budget above proof-vendor spend, and proof vendors must prefer partnership over bundling. That makes this a plausible pre-seed meet-and-investigate case only if early pilots confirm budget, false-positive tolerance, and channel cooperation.

Problem

• UK-facing apps with teen traffic now need auditable age-banded controls across signup, direct messaging, feeds, quiet hours, and AI features, but most mid-market teams only have point verification tools or manual flags.
• Choosing one proof method is not enough because UK rules, privacy duties, and complaints requirements force buyers to combine uncertain signals, step up risky cases, and explain every decision without broadly retaining passports or selfies.

Solution

• Build an SDK plus policy engine that accepts multiple age proofs, outputs only age band, confidence, jurisdiction, and consent state, and returns allow, block, or step-up decisions for each risky product surface.
• Add a versioned rules console, audit log, and appeals workflow so legal, trust-and-safety, and engineering teams can ship UK controls quickly and update them as UK, EU, and Australian rules diverge.

Why we win

• The company owns the layer between proof and product behavior, which age-verification vendors, app stores, and generic feature-flag systems do not solve well for independent apps.
• If it becomes the system of record for rule versions, overrides, appeals, and cross-surface integrations, switching costs compound faster than in a standalone proof API.

Milestones

flowchart LR
  Wedge[UK teen-policy wedge] --> MVP[Multi-surface policy engine MVP]
  MVP --> Proof[Paid pilots and audit proof]
  Proof --> Expansion[Jurisdiction and account expansion]

Founding team

Experiment roadmap

Risk assessment

What must be true

• At least 5 target apps confirm that UK youth compliance is a funded roadmap item within 12 months and name a budget owner.
• Buyers need multi-surface controls such as direct messaging, AI personas, feeds, or quiet hours, not just a signup age check.
• ICPs will pay roughly $120K-$200K ARR above proof-vendor spend for orchestration, audit logs, and appeals workflow.
• A layered proof strategy can meet buyer-accepted false-block and correction SLAs without broad raw-ID retention.
• At least one proof-vendor or counsel channel can generate qualified pilots faster than founder-led outbound alone.

Open diligence questions

• Which budget closes first in practice among legal and compliance, trust and safety, product, or a board-mandated special project?
• Which risky surface triggers the first purchase most often among direct messaging, AI personas, feeds, quiet hours, or signup?
• What false-positive rate and appeal SLA will buyers and regulators tolerate for 16 to 17 users and adults?
• How likely is UK guidance to narrow supplier choice to one approved proof method or list?
• Do Yoti, OneID, VerifyMy, or similar vendors want to resell orchestration or build it themselves?

Model sanity

• Revenue engine. Base-case Y3 revenue is driven by growing from 8 to 18 paying logos and monetizing each at a $190K blended customer-year value within the BP pricing band.
• Must go right. Pilot-to-production conversion and partner-sourced introductions must stay strong enough to add about 10 net new logos after Y2 without pulling forward a much larger field team.
• Model breaks if. If pricing slips toward $175K per customer-year or the sales cycle delays the ramp toward only 15 Y3 exit customers, cash compresses toward the downside low point of about $79K.
• Next-round proof. The seed case is credible once the company reaches roughly 12 production customers, 2 repeatable channels, and the first multi-jurisdiction expansions by Q2Y3.

Scenarios

Sensitivity

flowchart LR
  PartnerChannels[Founder + partner channels] --> PaidPilots
  PaidPilots --> ProductionCustomers
  ProductionCustomers --> Revenue
  Revenue --> GrossProfit
  GrossProfit --> Cash

Flags: The model depends on buyers funding a separate orchestration layer at roughly $190K per customer-year; if proof vendors bundle enough policy logic, both ARPU and CAC deteriorate quickly. · The downside case stays only barely cash-positive even with a $2.2M raise, so a two-quarter sales-cycle slip would require tighter hiring control or an earlier seed process. · Customer counts are milestone-driven net adds while churn is used only for LTV math; once the first renewals land, cohort retention should replace the heuristic churn input. · Revenue per FTE reaches only about $198K in Y3, which is reasonable for a services-assisted compliance wedge but below what investors would expect from a fully standardized SaaS motion.

• Method mandate lock-in. If the UK later mandates one narrow proof method or approved supplier set, a generic orchestration story could shrink. Mitigation: Own the feature-policy and audit layer above any mandated proof method, and integrate quickly with whichever suppliers regulators or platforms standardize on.
• Incumbent bundling. Identity and trust vendors could add lightweight age-policy features and bundle them into existing contracts. Mitigation: Go deeper on consumer-product surfaces like messaging, feeds, quiet hours, and AI personas where generic verification vendors do not model workflow or evidence needs well.
• Customer avoidance. Some smaller apps may simply block UK minors or exit the segment instead of paying for compliance software. Mitigation: Target apps where UK youth traffic and chat or AI engagement are revenue-critical, then expand into adjacent global youth-safety rules once the product proves ROI.