NELLA Labs product
Treating identity verification as orchestration rather than integration
Verification modelled as a configurable, resumable sequence of steps with an append-only evidence trail, so adding a market or replacing a provider is a configuration change rather than an engineering programme.
- Client
- Daju Verify — a NELLA Labs product
- Status
- In private beta
- Year
- 2026
- Sector
- Financial services and fintech, Government and public services
This is a NELLA Labs product or platform, not an external commission. Nothing here implies a client engagement.
Context
Daju Verify is a NELLA Labs product. It came out of repeatedly seeing the same failure across engagements: organisations integrating one verification vendor per country and ending up with several incompatible processes, several audit trails, and no way to change supplier without a re-integration.
Challenge and constraints
- Verification requirements differ by country, by product and by risk level, and the differences are in the sequence of steps, not just the data sources.
- A provider outage mid-verification must not lose the case or force the customer to start again.
- Every decision has to be reconstructable months later, including which rules applied and who overrode what.
- Biometric data is special-category, and treating it like ordinary application data would be indefensible.
Discovery
What we found, and what it changed
Research is only worth doing if it changes a decision. Each finding below is paired with the design or architecture change it caused.
Finding
Hard-coded verification flows were the single largest source of change cost in the engagements that prompted the product — a new market meant a new flow implementation.
What changed
Verification sequences became data: configurable steps with conditional branching, executed by an engine.
Finding
Provider timeouts during a verification left cases in an ambiguous state that operations teams resolved manually.
What changed
Execution moved to durable, resumable workflows so an outage suspends a case rather than losing it.
Finding
Reviewers were being handed a numeric risk score with no components, and were effectively rubber-stamping it.
What changed
Risk signals were exposed at component level in the review workspace, with the reasoning shown alongside the score.
Finding
Customers abandoned verification when asked for documents without explanation more often than for any other reason.
What changed
The flow states what will be checked, why, and what happens to the data before requesting anything.
Solution
What we built
- A step engine executing verification sequences defined as data, with branching on earlier outcomes.
- Durable workflow execution so provider outages suspend rather than fail a case.
- Every provider — document, biometric, registry, data source — behind one interface, so substitution does not touch the domain model or the audit format.
- An append-only evidence store recording every check, decision and override with attribution.
- A reviewer workspace presenting evidence and component-level signals rather than a single score.
- Separate, explicit consent for biometric processing, with defined retention and actual deletion.
Journeys
How people move through it
Customer: informed verification
See what will be checked and why, give scoped consent, capture document and liveness, and receive a specific outcome with a route to review if needed.
Reviewer: deciding on evidence
Work a risk-prioritised queue with full evidence, component-level signals, a recorded request-for-information route, and a decision written to the audit trail with reasoning.
Developer: integrate once, configure thereafter
Exercise a sandbox with deterministic identities, verify signed webhook handling including replay attempts, then add markets through configuration.
Architecture
Decisions and the reasoning
These are the choices that would have been expensive to reverse. Each one is recorded as an architecture decision record in the project.
Verification sequences as data executed by a durable engine.
It moves market and risk-level differences out of code entirely, which is what makes adding a country a configuration task and keeps one audit format across all of them.
Append-only evidence store rather than mutable case records.
The product’s value to a regulated customer is the ability to reconstruct a decision. A mutable record cannot provide that, whatever the change log says.
Biometric data isolated with separate consent, storage and retention.
Special-category data should not sit under the same access model as an email address. Separating it made retention and deletion implementable rather than aspirational.
Signed, idempotent, replay-resistant webhooks with dead-letter handling.
Consumers integrate once. Webhook reliability is the part of the API they will judge the product on, and it is very expensive to retrofit.
Security, accessibility and quality
- Sandbox parity
- Deterministic test identities producing every outcome path, including provider failure and review escalation.
- Replay resistance
- Webhook signature and replay tests run in CI, including clock-skew and duplicate-delivery cases.
- Data protection
- Retention and deletion for biometric and document data implemented and tested, not documented only.
- Audit
- Append-only trail with automated tests asserting that no path mutates a recorded decision.
Timeline
- Shape5 weeksProvider landscape assessment, regulatory screening across three markets, DPIA triage.
- Design4 weeksCustomer flow, reviewer workspace, API and webhook contract design.
- BuildOngoingStep engine, provider abstraction, evidence store and review workspace.
- ValidateContinuousSandbox parity, replay resistance and retention testing in every increment.
Team shape
- Product lead
- Solutions architect
- Two platform engineers
- Security engineer
- QA specialist
Technologies
- TypeScript
- Postgres
- Durable workflows
- Signed webhooks
- Provider abstraction
Outcomes
What we can actually substantiate
Each statement is marked either verified — meaning it is demonstrable in the system — or design intent, meaning it is what the design sets out to achieve and has not yet been measured in production.
- VerifiedAdding a market is a configuration change rather than a code change.
- VerifiedProvider outages suspend a verification case rather than losing it.
- VerifiedEvery decision, including human overrides, is reconstructable from an append-only trail.
- VerifiedBiometric data is stored, permissioned and deleted separately from ordinary application data.
Next stage
What comes next
- Additional country data sources behind the existing interface
- Business verification including ownership and control structures
- Configurable risk rules with versioning and simulation against historical cases
Related
Keep reading
Work
Building verification into the centre of a learning marketplace
A tutoring marketplace where an educator profile is invisible to families until identity and credentials have been checked, and where sessions accumulate into curriculum-level progress rather than billable hours.
Work
Modelling the tenancy, not the transaction
A property platform built around the tenancy as the central record, so applications, agreements, payments, maintenance and communications form one continuous, attributable history.
Next step
Have a problem shaped like this one?
Start with the Project Architect and you will get the same structure — problem, constraints, architecture direction, delivery path — for your own situation.