Buying and implementing identity verification

A sound identity purchase begins before the shortlist and continues after the SDK goes live. Define the decision, evidence and operating model; compare methods; pilot representative risks; contract for change and incidents; and monitor production outcomes.

For: procurement, product, compliance, privacy, security and operations leaders. This is independent information, not legal, compliance or security advice.

Lifecycle

1. Frame: use case, population, consequence and assurance.
2. Design: method, data, fraud, accessibility and fallback.
3. Source: requirements, evidence, shortlist and demonstrations.
4. Pilot: representative users, attacks, failures and operations.
5. Contract: scope, SLA, data, incident, change and exit.
6. Operate: monitor, review, improve and revalidate.

Build, buy or orchestrate

Build only where identity capability is strategically distinctive and the organisation can maintain document, fraud, standards, privacy and support expertise. Buy for established capability and evidence. Orchestrate multiple providers where coverage or resilience justifies extra complexity; avoid treating orchestration as automatic independence from lock-in.

Integration models

Model	Trade-off
Hosted flow	Faster delivery, less UX/control and another domain boundary
Web/mobile SDK	More integrated UX, version and platform maintenance
API/custom capture	Maximum control, largest security and compliance burden
Orchestration	Routing flexibility, added data/control dependency

Total cost

Model successful and failed attempts, retries, manual review, minimum commitments, fraud loss, engineering, support, privacy/security review, incident work and exit. A low per-check headline can produce a high cost per successfully onboarded legitimate user.

Production metrics

• Completion, abandonment and time.
• False outcomes and confirmed fraud.
• Retries, technical failure and manual review.
• Accessibility, fallback, complaints and appeals.
• Cost per successful legitimate outcome.
• Provider uptime, latency, incidents and material changes.

Evidence and limits

MyID separates enacted rules, official implementation material, testing and vendor claims. A source can establish what its publisher says; it does not prove that every product, deployment or interpretation works as claimed. Where Irish implementation remains unsettled, this page says so.

• NIST SP 800-63A-4 identity proofing
• ENISA Remote Identity Proofing: Attacks and Countermeasures
• General Data Protection Regulation
• Central Bank of Ireland AML/CFT guidance

Sources checked 22 August 2026. Re-check the linked primary material before making a consequential decision.

Next useful pages

• RFP questions
• Pilot plan
• Provider directories