Our approach

Evidence, not a verdict

Kenshiki does not replace the lender's decision. It asks narrower questions, gathers bounded corroboration, and returns a record a reviewer can inspect.

Proof moves. Raw data stays put.

Ask

What needs to be true?

Kenshiki sends the smallest possible evidence question.
Compute

The source answers on its side.

The provider checks against consented data without sending a raw feed.
Return

Only the bounded result comes back.

The answer can support, weaken, or contradict the file.
Record

The boundary is visible.

The reviewer sees what was checked and what Kenshiki did not take.

Proof without possession

Kenshiki does not collect more data. It asks better questions of data that stays where it is.

How corroboration works

Bring the question to the data. Bring back the answer.

Ask a bounded question

Each check is one narrow question: does the claimed person, place, and income hold together?

Keep data with the source

Providers compute on their side and return a verification result. Kenshiki never ingests more detail than the question requires.

Seal a reviewable record

The lender opens a record of evidence, reason codes, gates, and what Kenshiki deliberately did not take.

Evidence architecture

Six corroboration axes, one consented identity gate, and one Kenshiki SDK surface.

Each axis tests one slice of the file’s coherence; uncertainty stays visible.

Triangulation: no single signal settles whether a file is real — the intersection of several independent ones does.

Gate

eCBSV identity gate

Consent-based SSA match/no-match verification before corroboration.

A match is necessary but not sufficient; it is not proof of a coherent life.

01
core

Score-back presence verification

Spatiotemporal presence

Asks a provider-side area-and-time question without acquiring raw location data.

Example

The life has a durable footprint.

Separates

A real but quiet file from an identity assembled for one transaction.

Boundary

Kenshiki does not buy, ingest, or store raw location trails.
02
core

Carrier attestation

Carrier-attested telecom

Checks whether line tenure and device signals cohere with the claimed identity.

Example

The number behaves like it belongs to the person.

Separates

Seasoned personal continuity from newly assembled contact infrastructure.

Boundary

Carrier signals corroborate continuity; they do not expose message content.
03
core

Identity and consumer data graph

Address and residency

Checks whether address and residency signals support the claimed life pattern.

Example

The address behaves like a residence, not just a field.

Separates

A real residence from a mailbox, borrowed address, or thin surface match.

Boundary

Residency corroboration supports context; it is not lifestyle scoring.
04
core

Payroll verification

Income at source

Checks whether income evidence can be verified at an authoritative source.

Example

The claimed income has a source-backed trail.

Separates

A stale risk snapshot from a materially recovered income picture.

Boundary

Income evidence supports capacity review; it is not an automatic approval.
05
core

Open banking

Open-banking cash flow

Checks whether account history supports the rhythm of the requested obligation.

Example

The payment rhythm has recovered.

Separates

A bounded hardship from an ongoing inability to support the obligation.

Boundary

Cash-flow fit avoids merchant-level storytelling and stays bounded to evidence.
06
core

Identity resolution

Identity-element trace

Tests whether identity elements have a seasoned, continuous history.

Example

The identity has history, not just matching fields.

Separates

A valid-looking profile from a lived identity with durable history.

Boundary

Identity continuity complements eCBSV; it does not replace consented verification.

Kenshiki-built signal

Kadai SDK & API

The SDK records a behavioral-biometrics session during the application flow and returns a token.

Raw biometric data stays on device; Kenshiki receives a session token, not the typed content.

The customer API returns the already-sealed evaluation; it does not re-decide the file.

Request a briefing Start with presence proof

Spatiotemporal presence, in detail

We never need to know where someone is.

We need to know whether presence is consistent with the file in front of us. A signal can be accurate without being precise: confirming that presence fits a declared region is different from pinpointing a person on a street corner.

We send a region; the provider checks presence on their side. Raw location never enters our system.

Provider layer

A trust strip, not a logo wall.

The evidence layer

Built on corroboration signals lenders already trust

Kenshiki binds independent corroboration signals into the decision record. Named providers stay review-gated until the integration is real and public naming is approved.

Open telecom standard

Spatiotemporal presence · Carrier-attested telecom

[Standard — public] [NAME-OK: standard]

Identity resolution and telecom data

Carrier-attested telecom · Identity-element trace