An identity check that rejects the wrong person costs more than a lost customer. Someone is locked out of a bank account, a wallet or a job, often with no idea why. We are building Saolix K2M on the view that every rejection should come with a reason, a second pair of eyes when the stakes are high, and a fair route for the decision to be challenged. K2M is in pre-release; this piece describes how it is designed, and what the current release already does.

Consent comes first

K2M's capture flow asks for consent before any biometric step. The applicant confirms consent to biometric processing, data retention and identity verification, and the consent is recorded with the session. Only then does the flow move to the document and the selfie.

Minimums nobody can quietly lower

Automated checks produce scores: how closely the selfie matches the document photo, how confident the liveness check is, whether the image is good enough to trust. Every system has thresholds for these. The question is who can change them.

In K2M, the hard minimums are constants written into the code, frozen and commented as not overridable through any interface, configuration or admin screen. Among them:

  • a minimum face-match similarity
  • a minimum liveness confidence
  • a verified one-time passcode on the applicant's phone, where one is used

In the current release, a face match or liveness check below its minimum is marked as failed, and the reviewer makes the decision. K2M's design goes further: a failed check scores zero for that part of the assessment, so it cannot be averaged away by strong results elsewhere. Changing a minimum means changing the software in a new release, not flipping a setting on a busy afternoon.

Changing a minimum means changing the software, not flipping a setting.

Two reviewers when it matters

Some decisions are too consequential for one person. K2M requires dual approval for high-assurance sessions, and for sessions with a high risk score recorded in the review. These rules are enforced in code:

  • the same reviewer cannot give both approvals
  • reviewers cannot review their own session
  • if the two reviewers disagree, the session is marked as escalated rather than finalised

A real route to appeal

In the current release, staff open an appeal against a rejection in K2M; an applicant-facing appeal is part of the design. K2M only accepts an appeal on a session that was actually rejected with a recorded reason, and allows one pending appeal at a time. The appeal is decided by a compliance officer or a KYC administrator, and never by the reviewer who recorded the rejection. They record whether the rejection is upheld or overturned, and why, against the appeal.

Keeping that reviewer out matters. Without it, an appeal is just the same person being asked to change their mind.

The K2M decision path: consent, automated checks against hard minimums, first reviewer, second reviewer for high-risk sessions, then an appeal decided by someone other than the reviewer who recorded the rejection. A DECISION WITH A ROUTE TO CHALLENGE IT Consentbefore capture Checksvs hard minimums Reviewer Adecision Reviewer Bhigh-risk only Appealnot the rejecting reviewer AUTOMATED CHECKS INFORM · PEOPLE DECIDE, AND CAN BE CHALLENGED
Automated checks sit above the line. Decisions, second reviews and appeals sit below it, with named people accountable at each step.

A record protected from editing

K2M's audit tables (admin actions, evidence chain of custody and session step history) are protected by the database itself: triggers reject updates and deletes.

Why this matters beyond compliance

Regulators increasingly expect automated decisions about people to be explainable and contestable. But the stronger reason is trust. Customers who are rejected fairly, told why and whose rejection can be looked at again by someone else have reason to trust the answer, including when it is yes.

You can follow a rejection through four-eyes review and appeal in the K2M Simulator, which shows K2M's intended design.