Assurance levels
The two recipient assurance tiers, email and id_verified, what each one means, how it is established, and why it gates what a recipient can receive.
Every recipient holds an assurance level: how strongly Keepable knows who
they are. It is reported on the account profile as
assurance_level and takes exactly one of two values.
assurance_level | Established by | In plain terms |
|---|---|---|
email | A partner provisioned the recipient by email, and the recipient claimed the mailbox via a one-time link. | Keepable knows the person controls a mailbox, not who they are. This is a self-asserted identity. |
id_verified | The recipient verified a strong national identity anchor (a NIN or a BVN) with biometric identity verification and consent. | Keepable has validated a government-backed identity against its issuing source. This is the high-assurance tier. |
What each tier means for the recipient
email proves mailbox control and nothing more. Verifying an email shows
the person can receive at that address, but it does not establish their legal
identity. This tier exists so partners who hold only a name and an email (a
school, an employer, a clinic) can still reach people, but it deliberately sits
below a fully identity-verified account.
id_verified is the Keepable norm. It anchors the recipient on a strong,
registry-backed Nigerian identifier (NIN or BVN), verified through biometric
identity checks and recorded consent. NIN is the canonical anchor; a recipient
who verifies by BVN is still id_verified.
Why the level matters
Assurance levels are hierarchical for authorization: a higher level
satisfies any lower requirement, and a lower level must not reach a
higher-assurance service. In practice this gates what a recipient may receive.
Sensitive, identity-bound mail (think official correspondence that legally must
reach a verified individual) is reserved for id_verified recipients, while an
email-tier recipient sees the content appropriate to a mailbox-control-only
identity.
Email is a one-time proof of mailbox control, not an ongoing authentication
factor. After onboarding, recipients authenticate with a passkey regardless of
tier. An email-tier recipient does not become id_verified simply by
verifying their email; that upgrade requires verifying a strong identity
anchor.
Reading the level
assurance_level is omitted from the profile when there is no profile row on
file yet. Once a profile exists it is always one of email or id_verified,
and the apps can branch on it directly.
Email verification
Capture a recipient email and prove control of it with a one-time code. PUT /recipient/account/email issues a code, POST /recipient/account/email/verify redeems it, both idempotent.
Delivery notifications
How a recipient learns mail arrived, gated by their notification preferences, including the held-pending to delivered release that fires when a previously-unreachable recipient signs up.