engineering · 29 June 2026
How selective disclosure works in a Moxim credential
One credential, three views: the engineering behind showing a broker what they need while the deeper detail stays sealed until you consent.
By Moxim Team
Across this site we make one claim repeatedly: one credential, three views. You hold everything; a broker sees what they need to help you; the deepest detail opens only with your explicit consent. This post explains how that actually works under the bonnet, because "trust us, it's selective" is not an engineering answer.
The problem with sharing documents
When you email someone a PDF of your bank statement, you share all of it. There is no way to hand over the income summary but keep the line-by-line detail of where you shopped last month. Documents are all-or-nothing, and once sent, they are out of your hands.
A readiness credential needs to do better than that. The same record has to serve three very different audiences: you (everything), a broker (the readiness picture, without the behavioural detail of your spending), and, in time, a lender (the deeper evidence, but only when underwriting genuinely needs it and only with your consent).
SD-JWT: claims that can be disclosed one at a time
The mechanism we use is called SD-JWT, short for Selective Disclosure JWT, an open standard developed in the IETF, the body behind most of the internet's plumbing.
The idea, in plain terms:
Each module of the credential is sealed separately. Instead of one big signed blob, each claim group — identity, income, the affordability read, the behavioural detail — is individually salted and hashed. The issuer signs the collection of hashes, not the raw values. (Today the sealed unit is the module; sealing each individual field within a module is the standard's next step, and one we intend to follow.)
You hold the values; the credential holds the proofs. When you share with a broker, you present the issuer-signed credential plus only the disclosures you choose. The broker's software can verify that each disclosed value matches its hash and that the issuer's signature covers it, without ever seeing the claims you withheld.
Withheld is not deleted. The undisclosed claims still exist, still sealed inside the same credential. If you later consent to the deeper view, those disclosures are released against the same signature. Nothing is re-issued, and nothing can be quietly altered in between: change a single value and its hash no longer matches, so the record is tamper-evident by construction.
Disclosure groups: how the three views are drawn
On top of SD-JWT we define disclosure groups, which are simply named bundles of claims that travel together:
- The holder view is everything. It is your record; nothing is hidden from you.
- The broker view carries identity (with its KYC and AML screening results), Government-sourced income (HMRC), the affordability read, property detail, credit where you have authorised it, and the factual account summary from your bank connection. The behavioural open-banking detail — the conduct signals in your transaction history — is not in this bundle.
- The lender view adds that behavioural evidence back, and exists for one reason: underwriting sometimes legitimately needs it. It opens only with your explicit consent, case by case.
The boundary between views is enforced by the mathematics of the format, not by a settings page. A broker cannot "scroll down" to the withheld claims, because the disclosures for those claims were never given to them.
The tooling: open standards, open source
We build on open standards end to end: the W3C Verifiable Credentials data model for the credential's structure, SD-JWT for selective disclosure, and the OpenID for Verifiable Credentials family of protocols for issuance. The issuance service in our platform runs on the walt.id Community Stack, an open-source (Apache-2.0) toolkit for W3C credentials and SD-JWT used across the European digital-identity ecosystem.
We choose open tooling deliberately. A credential you own should not depend on proprietary formats only one company can read. Any verifier that speaks the standards can check a Moxim credential's integrity, which is the whole point of portability.
Where this stands today
Honesty section. The selective-disclosure pipeline is in active development: the issuance service is integrated in our development environment, and the credential you can see in the illustrative experience today is exactly that, illustrative — synthetic data, an illustrative seal, no real issuance. The mechanics described above are what ships when your real connected data flows through it, with early access ahead of the broker pilot.
We would rather explain the engineering accurately now than wave at "bank-grade security" and hope nobody asks follow-up questions.
Everything Moxim shows today is illustrative and educational, never a quote, an offer, or a lending decision. Moxim is not yet PRA-authorised or FCA-regulated. If you would like to see where you stand, see the experience.