Super-flexible KYC, explained end to end.

1. Product overview

Evidencer is a self-hosted system for defining KYC requirements, collecting evidence securely, reviewing it with controlled decisions, and proving exactly why a subject is or is not compliant.

2. Roles and access

Menus control what a user sees; capabilities control what they can do; settings tabs control administration; class scope limits populations.

1. Open Settings → Roles & access.Select or create a role.
2. Choose menus and settings tabs.Settings remains available so all users can reach Profile.
3. Assign capabilities.Operations, Review, Override, Configure, Administer and Release claims are independent.
4. Apply class scope.Product scope includes the parent KYC class for inherited requirements.
5. Optionally require approval.New fields, documents and classes enter the approval queue.
6. Use View as this role.The preview changes UI visibility and filtering; APIs still use your real identity.

3. Sign in and navigation

1. Enter email and password.Repeated failures trigger the configured lockout.
2. Replace a temporary password.Use Profile & password; minimum length is eight characters.
3. Review new-browser alerts.They can include browser, OS, IP, time and optional approximate location.
4. Use left navigation and global search.Search by name, reference, email or registration number.
5. Use the user menu.Manage profile, theme and sign-out; use the bell for assignments, hand-offs and SLA alerts.

4. End-to-end KYC lifecycle

1. Publish a class version.Only an effective published version can assess new work.
2. Create a record.Primary keys are normalized; a match prevents duplication or adds the new class.
3. Initialize assessments.A product class also enrolls its parent and inherits requirements.
4. Issue a secure request.Select scope, items, expiry, mode, verification and delivery channels.
5. Applicant verifies and submits.Drafts can be saved; files are chunked, signature-checked, scanned, fingerprinted and optionally extracted.
6. Reviewer claims and decides.Dual workflows add a checker; rejected items can generate targeted rework.
7. Engine recalculates.Conditions, alternatives, reuse, waivers, holds and expiry are applied deterministically.
8. Monitor and renew.The scheduler sends renewal and SLA alerts; approved replacements supersede old evidence.

5. Technical flowcharts

These lane diagrams are configuration references. Each node names a product action or state boundary; arrows show the normal sequence and decision nodes show policy branches.

6. Operational dashboard

7. Records and subjects

1. Select New record and an active class.It must have a published version.
2. Complete every primary key.These values identify the subject; display name is optional.
3. Create.A same-class match is blocked; a cross-class match extends the existing subject.

8. Create and deliver a KYC request

A KYC request is a scoped, expiring form for one existing record. Evidencer sends the form link to the recipient and, when one-time-code verification is selected, sends the secret through the same selected delivery channel or channels so the recipient can authenticate and update information.

Before creating the request

Operator procedure

1. Open Records and select the subject.Confirm identity, classes, assessment versions and current blocking items.
2. Select Issue request.Choose one or more enrolled classes. Evidencer proposes the outstanding fields and documents from applicable mandatory, conditional and rework requirements.
3. Review the item list.Include only what the recipient must update. A rejected-item rework request should contain the rejected field/document plus any explicitly linked correction.
4. Choose request mode.Single-use is consumed after a successful submission. Reusable allows draft/staged updates until expiry or revocation.
5. Choose verification.None relies on possession of the secret URL; Date of birth compares the entered DOB with the record; One-time code adds a short-lived secret.
6. Select delivery channels.Email, SMS, WhatsApp, Discord DM and/or the generic signed messaging webhook can be selected if configured. For OTP requests, the form link and the verification secret travel through the same selected channel set.
7. Set expiry and recipient.The default lifetime comes from Settings → Reminders & links. Confirm the destination carefully.
8. Create and send.Evidencer stores the request, constructs the tokenized URL, renders the channel template and dispatches the message. The notification and audit logs record the attempt and outcome.
9. Monitor.Track delivery, opened, verified, draft-saved, submitted, expired or revoked states. Revoke immediately if the destination was wrong or the URL may be exposed.

What the recipient receives

Form characteristics

• Token-scoped: the recipient cannot browse other records or classes.
• Dynamic: conditional requirements update as source answers change.
• Validated: field patterns, ranges and allowed values come from the field library.
• Resumable when reusable mode is selected; draft saves do not create reviewer decisions.
• Document-aware: type, maximum size, minimum/maximum count and expiry metadata are enforced.
• Secure uploads: chunks are assembled, content-signature checked, scanned and SHA-256 fingerprinted.
• Accessible status: progress separates completed, outstanding and invalid items.
• Auditable: open, verification, draft, upload, submit, expiry and revocation events are recorded.

Delivery failure and recovery

If no selected channel can deliver, the request remains visible but the recipient may not have received it. Inspect Settings connection tests and the notification log, correct the destination/configuration, then issue a fresh request or securely convey the existing link according to policy. Demo fallback code 123456 must never be treated as a production delivery mechanism.

9. External applicant portal

1. Open the unexpired link and verify.Revoked, expired or consumed single-use links cannot continue.
2. Complete fields.Help and validation come from the library; conditional items update live.
3. Upload documents.Follow type, size and count rules; chunk progress is visible.
4. Resolve extraction prompts.Low-confidence results need human confirmation and never overwrite approved values silently.
5. Save draft if allowed; then submit.The final action validates all current mandatory items and produces a receipt.

Processing that occurs while the form is completed

10. Review and decisions

1. Open and claim.Prioritize overdue/high-risk cases and prevent competing work.
2. Inspect every pending item.Check preview, metadata, expiry, scan, fingerprint and extraction provenance.
3. Approve or reject.For rejection, choose a reason and write clear applicant remediation; keep internal notes separate.
4. Complete dual control when configured.Self-approval is governed by policy.

11. Reports and SLA

12. Field library

1. Set stable code and name.Codes are integration identifiers.
2. Choose type.Text, number, date, boolean, country, address, select, identifier, calculated or API-derived.
3. Add description/help, sensitivity and owner.Unmasking sensitive/secret values is audited.
4. Define validation.Length, regex/message, min/max/precision, values and uniqueness depend on type.
5. Set introduction/retirement dates.Retire definitions used by history instead of deleting.

Configure automatic derivation

1. Select the source fields.These are the values that must be present before automatic execution, such as country plus registration number.
2. Configure request construction.Choose method, URL, headers/authentication and query, JSON or form mappings. Never place secrets in visible field values.
3. Configure response mapping.Point the response path to the value to store and define any normalization.
4. Set freshness and auto-fetch.Fresh values are reused; a source-field change invalidates provenance and schedules a new fetch.
5. Choose failure behavior.Retry, allow manual fallback, or keep the requirement blocked.
6. Test with samples.Verify request rendering and response mapping before attaching the field to a published class.

13. Document library

Clone similar definitions. Delete is blocked when referenced; retire instead. Changing linked metadata after approval supersedes evidence and requests a fresh upload.

14. Classes, versions and requirements

Define code, name, kind, subject type, primary keys, owner, jurisdiction, workflow, SLA and status. Product classes also select product and parent.

1. Create a draft and set effective dates/notes.
2. Add requirements.Choose field/document, necessity, order, instructions, dates, approver and reuse.
3. Add conditions.For example RISK_BAND == "High"; test true and false paths.
4. Use alternative groups.They express one-of rules such as Passport or National ID.
5. Review inheritance and impact.Confirm affected records and new blockers, then publish.

15. Configuration approvals

1. Maker submits a new field, document or class.It remains unusable while pending.
2. Admin opens Settings → Configuration approvals.Inspect the full definition, author and timestamps.
3. Compare resubmission diff.Verify corrections after rejection.
4. Approve or reject with a note.Approval activates; rejection provides actionable feedback.

16. API clients and webhooks

1. Set name, owner and environment.
2. Grant scopes.status:read, request:create, and items:disclose are separate.
3. Restrict classes and rates.Set per-minute and burst limits.
4. Save the secret once.Store it in a secret manager; it is shown only at creation/rotation.
5. Use code generator and simulator.Inspect exact HTTP status/body before integrating.

GET /api/v1/kyc/status?classCode=IND&recipientEmail=person@example.com
Authorization: Bearer kyc_live_…
X-Correlation-Id: your-trace-id

With request:create, “start KYC at source” can create an unknown subject and return a secure URL. Item detail requires items:disclose.

Webhooks

Add multiple endpoints with independent secret, events and delivery history. Consumers verify the raw-body HMAC, reject stale/replayed messages, respond 2xx quickly and process idempotently. Test, monitor retries, rotate with overlap, then remove old endpoints.

17. Audit and evidence

Events cover authentication, links, submissions, decisions, configuration, derived calls, sensitive views, reminders, holds, imports and API checks. Filter then export. Correlation IDs connect browser/API activity to notifications and webhook delivery.

18. Platform settings

1. Enter values and save.Existing secrets appear only as stored placeholders.
2. Run the saved-connection test.Unsaved edits are not used.
3. Inspect health and audit.Verify success before enabling dependent workflows.

19. Security and production

1. Pre-flight.Change demo passwords; configure TLS/public URL, delivery, storage, backup and real admins.
2. Open Security → Move to production.Review impact and type the confirmation phrase.
3. Confirm.Demo records are removed and demo users deactivated; configuration remains.
4. Smoke test.Create, deliver, upload, review, query status and verify audit/webhook.

20. Status model

Most blocking wins: hold, rejection, missing/submitted, expiry, expiring-soon, then compliant. Optional items do not block; false conditions do not apply; one valid alternative satisfies its group; a valid waiver satisfies its target.

21. Troubleshooting

22. Quick reference

End of manual · Evidencer user and administrator guide.