Wallet profiles · Wallet profiles
Bank customer — verified-customer credential
Wallet profile that accepts a "verified customer of bank X" credential — usable at partner services to skip re-KYC.
- bank
- kyc
- partner-onboarding
Tested against:broker: 1.0.0arf: 1.4
Use case
A retail bank issues a "verified customer of us" credential after KYC. The customer can then present that credential at partner services (a brokerage, an insurer) to skip re-KYC. The partner service trusts the bank's KYC level rather than running its own document upload.
Wallet profile (YAML)
id: bank-customer
name: "Verified bank customer"
accepted_formats:
- vc+sd-jwt
trust_registry_url: https://trust.thoryn.org
allowed_issuers:
- "did:bank:rabobank"
- "did:bank:abn-amro"
- "did:bank:ing"
# any partner bank you trust
session_ttl_seconds: 600
require_holder_binding: truePresentation definition
{
"id": "bank-customer-pd",
"input_descriptors": [
{
"id": "customer",
"constraints": {
"fields": [
{ "path": ["$.vct"], "filter": { "const": "BankCustomerCredential" } },
{ "path": ["$.account_holder_name"] },
{ "path": ["$.kyc_level"], "filter": { "enum": ["LoA-medium", "LoA-high"] } },
{ "path": ["$.kyc_completed_at"] }
]
}
}
]
}The kyc_level filter rejects credentials below your assurance threshold; kyc_completed_at lets you decide if a stale KYC (e.g. older than 12 months) needs a refresh.
Sample webhook payload
{
"session_id": "...",
"vct": "BankCustomerCredential",
"claims": {
"account_holder_name": "Jan Jansen",
"kyc_level": "LoA-high",
"kyc_completed_at": "2025-11-12"
},
"verified_at": "2026-04-25T..."
}When to use
- Partner-onboarding flows where re-KYC is wasteful
- Multi-tenant SaaS where customers from a known bank get expedited setup
When not to use
- First-party onboarding — issue your own credential, don't accept others
- Regulated flows where the partner KYC isn't acceptable to your sector regulator