> Toden documentation. For the full index fetch /llms.txt. Every page is available as Markdown by appending .md to its URL. Identity verification uses /api/kyc, Risk Intelligence uses /api/v1; they are separate contracts with different error shapes. Never invent an endpoint, field or enum value: read the API reference page for the operation first.

## NFC chip trust

### Added

* **Chip reads are checked against government certificate lists.** Each
  issuing country's certificate authority (CSCA) comes from lists published by
  the German (BSI), Dutch and Italian governments, verified against each
  publisher's own key before use. 138 countries are covered, including Nigeria,
  Ghana, Kenya, Egypt, Ethiopia, Senegal, Rwanda, Uganda and Tanzania. A chip
  from a covered country whose data and signature check out reaches
  `nfcStatus: verified` and can earn the `chip` assurance level. A chip from a
  country not on the list reads `inconclusive` and the verification falls back
  to the document and the government database.
* **Cancelled signers.** Countries' cancellation lists are checked, and a chip
  whose signing certificate its country has cancelled is never treated as
  genuine (`nfc.sod.signerRevoked: true`, the chip reads `inconclusive`).
  A signer retired in the ordinary way (replaced, or the office closed) keeps
  the passports it already signed valid.
* **Decision field `verification.nfcSignerCancellationUnknown`** ("Passport
  signer's cancellation status unknown"): `true` when a chip is genuine but its
  country's cancellation list was unavailable or out of date, so we could not
  check whether the signer was cancelled. These chips are accepted by default;
  add a rule on the NFC step's Rules tab to review or decline them.
* `nfc.cloneCheck` and decision field `verification.nfcCloneCheck`: how a copied
  chip was ruled out (`active_auth`, `face_bound` or `none`).
* `nfc.activeAuth.reason` gains `dg15_withheld` (the chip's key was left out of
  the submission) and `signature_malformed` (the chip's answer could not be
  read). Neither fails a verification.

### Changed

* **Behaviour change:** a chip that fails Active Authentication (the chip
  answered our challenge with the wrong key, which is how a copied chip
  behaves) now fails the verification with `chip_not_authentic`. A chip without
  Active Authentication, an SDK that did not attempt it, or an answer that could
  not be read is never a failure.
* **Behaviour change:** the `chip` assurance level now also requires that a
  copy was ruled out: the chip proved it is the original (Active
  Authentication), or, for a chip without that feature, the selfie matched the
  chip photo. Otherwise the verification gets the next level (`gov_db` or
  `document`). On the government-database path (a Nigerian passport, for
  example) the selfie is compared with the government photo, so the chip
  reaches `chip` only through Active Authentication. Workflows that approve on
  `assuranceLevel eq chip` may route more verifications to their fallback.
* **Behaviour change:** SDK versions that do not send the chip's Active
  Authentication key no longer reach `chip` for passports that have one. The
  React Native SDK sends it from 2.5.0 and the Flutter SDK from 2.6.0.
* `supportsNfc` on `GET /api/kyc/config` (and on a workflow's ID types) is true
  only when the document carries a chip AND its issuing country is covered, so
  the chip step appears for newly covered countries and is not offered for the
  rest. Chip data submitted for an uncovered country is ignored and not
  charged.
* A chip is authentic only when the certificate it chains to belongs to the
  country the chip's own data names as its issuer.
* A copied chip reports `chipAuthentic: false`.

### Fixed

* A verification whose processing was retried after it had used its Active
  Authentication challenge no longer loses the chip's proof (and with it the
  `chip` assurance level).