Updated 2026-10-04: sourcing and wording.
A new class of tool is eating the expensive middle of compliance. According to Anthropic’s own announcement, its finance agents include a KYC screener that extracts fields from documents, screens watchlists and packages escalations as structured JSON. In its public response, Sardine argued that the reasoning itself is commoditising and that durable value sits in evidence quality and operational infrastructure.
Both are right, and both describe the input side of an identity credential. The MintID issuer plane is built on that distinction, and a module now enforces it.
Cheaper screening is good news for a credential rail
Lower screening costs directly benefit MintID. The economics of amortised accountability start when an organisation performs a real know-your-customer (KYC) check once. Every cheaper screener widens the set of organisations that can viably operate as an accepted issuer. An accepted issuer is a KYC organisation admitted on-chain to issue credentials. Every new issuer puts more credentials in circulation, and each credential can then be proven repeatedly in zero knowledge at no further screening cost.
The screener market can commoditise all it wants. Every cheaper screener makes a MintID credential cheaper to issue, and none of them can issue one.
Evidence and verdicts are different objects
The failure mode to design against is subtle. When a screener returns a structured payload containing a field called assurance, tier, or grade, an issuing system under deadline pressure might simply copy that value forward. At that moment, the accepted issuer stops deciding and starts forwarding, even though the credential it signs still states that the issuer assessed the person at that grade. This creates a hidden gap in the accountability chain.
To prevent this, the evidence profile enforces the boundary at the data-type level. The normalised evidence it produces has no field, optional or nullable, that could carry a grade. Any payload that asserts a grade or tier label is rejected outright wherever it appears and at any depth, including inside outcome strings shaped like a grade. Because the data structure cannot represent a grade, an issuer system cannot forward one from a screener.
What each grade certifies was settled in August 2026. The four assurance grades are anchored on eIDAS and aligned with ISO/IEC 29115. The issuer publishes how recently the evidence was checked as a separate freshness band. Our post on how we grade identity explains this model, and the KYC trust model records who makes the decision. This evidence profile does not assign grades. It ensures that only the issuer can assign them.
Accepted evidence becomes enumerated checks with provenance
Accepted evidence normalises into enumerated checks with enumerated outcomes: document authenticity, field-extraction consistency, identity-data validation, sanctions, PEP and adverse-media screening. Each check resolves to pass, fail, inconclusive or escalated. Each check also carries an attestation of how it was retrieved. That is either an authenticated API call or a signed webhook that was re-fetched over the authenticated channel before being believed. Nothing is trusted for returning JSON.
The screener’s own escalation disposition is recorded as one more enumerated check. A screener recommendation for approval carries the exact weight of a single check outcome. The issuer evaluates this recommendation as an input and does not execute it as an instruction.
Everything else is rejected with a named reason
Anything else is rejected, with a reason from a closed vocabulary:
| Rejected when | Why |
|---|---|
| case or subject mismatch | The payload describes a case or a subject different from the one this authority opened. Evidence that arrived for someone else is not evidence. |
| provenance missing | The payload lacks an attestation of how it was retrieved. Nothing is trusted for the mere fact of returning JSON. |
| bare verdict | The payload is reduced to “verified: true”. A boolean value is a conclusion without the underlying check results, so it is not auditable evidence. |
| grade asserted | The payload contains a provider-asserted assurance grade or tier label at any depth. The issuer decides the grade. |
| timestamps missing or evidence stale | The evidence is undated, or it is older than the issuing authority accepts at the moment of evaluation. |
| unknown check kind or outcome | The payload contains a check or an outcome outside the closed vocabulary. Every check kind and outcome must be explicitly defined to be accepted. |
The verifier reason codes apply the same closed-vocabulary discipline on the other side of the protocol. A named rejection is auditable, whereas a catch-all lets exceptions quietly become policy.
Deterministic normalisation, and nothing on the chain
The module is a deterministic function of its inputs. The caller injects the evaluation time. The module has no internal clock, network or randomness. The driver performs authenticated retrieval and attests to it through the provenance fields that the normaliser demands. A test suite holds that shape in place.
All screening material becomes issuer-private on arrival. No raw KYC data, personally identifiable information (PII) or screener payload ever touches the chain because the architecture has no place for it. A provider outage, an API change or a vendor switch is invisible to the protocol. The issuer integrates against the evidence contract, and that contract stays the same for any screening vendor.
The issuer decides the grade and stakes its bond on it
Keeping the issuance decision separate from automated screening is easy to state in a policy document, but harder to enforce under commercial pressure. Enforcing that separation in a data-type signature and a closed rejection vocabulary makes the rule structural. The accepted issuer decides the assurance grade after independent assessment and stakes its bond on that decision, while the screener supplies the underlying check results.