The ID is real. Was the consent?

Calmproof lets an EU digital identity wallet attach a signed, request-bound record of the situation to every presentation — an active call, a remote-access session, a relayed QR code — so the bank sees what the phone saw.

Pilot programme 2027 Watch the call happen

9:41

Call in progress · 04:12

Screen is being shared

EU Digital Identity Wallet

Presentation request fromNordbank

Name: Anna Weber
Date of birth: 12.03.1961
Address: Lübeck

You are on a callBanks and authorities never ask you to share your ID during a call. Pause, hang up, call the number on your card.Recorded for the bank as a category only — never who called.

What Nordbank receives#a91f

presentation: valid
binding: ok
context: risk 0
flags: []
decision: proceed

0Risk class 0 · calm

Change the situation on the phone:

Same presentation, different situation. Signals are read on the phone; only signed category flags travel.

Patent pending (DE) · filed 21 October 2026

Built for OpenID4VP, SD-JWT VC and mdoc. Category flags only — no identifiers, no call content, no location.

Everything checked out. Only the situation was wrong.

Without Calmproof
1
A call comes in. Police, the bank, the tax office. The voice is calm and in a hurry.
2
The caller asks for one small thing: confirm your identity in your wallet. It takes a tap.
3
The ID is genuine, the wallet is genuine, the bank is genuine. The call was the only false thing — and nothing recorded it.
With Calmproof
4
The same call, with Calmproof. Anna sees a warning, and Nordbank receives a sealed record: call in progress. The transfer waits until the bank has called her back.

9:41

Unknown number · 00:14

EU Digital Identity Wallet

Presentation request fromNordbank

Name: Anna Weber
Date of birth: 12.03.1961
Address: Lübeck

✓

You are on a callBanks and authorities never ask you to share your ID during a call. Pause, hang up, call the number on your card.Recorded for the bank as a category only — never who called.

74% of credit-transfer fraud value in the EU is the payer being manipulated (EBA/ECB joint report, December 2025). Under the coming EU Payment Services Regulation, the bank carries the loss when a fraudster impersonates it.

It reads the situation, protects the person, and gives the verifier proof.

Without Calmproof

Presentation valid. Proceed.

The verifier checks signature, binding and freshness. All green. The transfer is executed — while the customer is still on the phone with the “bank”.

presentation valid binding ok nonce matches context — decision execute

With Calmproof

Presentation valid. Context: call in progress. Call back first.

The same checks, plus a sealed record of the situation. The policy pauses the transfer and the bank calls the customer on the number on file — before the money moves.

presentation valid binding ok nonce matches context risk 2 · voice_call · sealed, bound decision hold · call back

Reads the situation, on the phone

In the moments of consent, the wallet checks a short, fixed list of signals: is a call running, is the screen shared or remotely controlled, did the request arrive from another device without proof of proximity, is the device intact. Nothing leaves the phone yet.

Protects the person

Depending on the risk class: a plain warning, a second confirmation, a short pause, or a refusal. People who rely on accessibility services are never flagged for that alone.

Gives the verifier proof

A small signed record, bound to that exact request, travels with the presentation: risk class and category flags only. No numbers called, no content, no location — and it cannot be detached or replayed.

The scams fraud teams already know — seen from the phone.

The police call
“Your account is being used by criminals. Confirm your identity so we can protect it.” A presentation during an active call from an unknown number.
voice_call → risk 2, call back first
The remote support
A “technician” installs a remote-control app to fix a problem that doesn't exist, then guides the person through a wallet presentation.
remote_access + voice_call → risk 3, refuse
The relayed QR code
The scammer opens an account in their own browser and sends the QR code to the victim, who scans it with their wallet. The presentation lands in the wrong session.
cross_device_no_proximity → risk 1–2
The shared screen
A screen-sharing session is running while the person consents. Someone else sees — or controls — the screen the ID is presented on.
screen_share → risk 2, pause
The call that goes on
The presentation looked calm; the call began a minute later and the next step is a transfer. A follow-up record, bound to the same request, tells the bank.
follow-up attestation → same request id

One extra object in the response the verifier already checks.

Same response, same key, same nonce. There is nothing to intercept, replay or detach.

1
The verifier asks
A bank, authority or service requests a credential and, optionally, the context attestation — through the standard request, with its one-time request identifier.

requestNordbank
noncea91f…3c
credentialPID
context_attestationrequested
2
The wallet looks around
While the person decides, the context unit reads operating-system signals and derives a risk class. The person is warned, slowed or protected if needed.

voice_callactive
screen_sharenone
remote_accessnone
deviceverified
risk class 2 · elevated
3
The record is sealed
Risk class, category flags, timestamp, hash of the request and of the presentation, capability vector — signed with the presentation key and, where available, a platform attestation.
```
{
  "risk_class": 2,
  "flags": ["voice_call"],
  "request_hash": "…a91f",
  "seal": "ES256"
}
```
4
The verifier decides
It checks seal, binding and freshness, then applies its own policy. A follow-up record after consent (“the call went on”) is bound to the same request.

seal · binding · freshnessvalid
proceedcall back firstdelaymanual review

Two clocks are running at the same time.

The wallets arrive first; the obligation to accept them and the liability for impersonation fraud follow within eighteen months. A pilot in 2027 lands exactly in the window in which banks rebuild their wallet acceptance and their fraud processes.

202624 Decemberevery EU member state must offer a wallet
20272 January 2027German wallet launches
202724 Decemberbanks and regulated services must accept it
2028expected mid-yearPSR: liability for impersonation fraud

Sources: Regulation (EU) 2024/1183 Art. 5a, 5f · Bundestag, 15 Oct 2026 · PSR final texts, April 2026

For banks and payment providers

Proof of the moment, for the day the loss is yours.

A signed context record for every wallet presentation, usable in your existing risk engine as one more input.
Evidence for reimbursement decisions and for supervisors asking what “appropriate fraud detection” looked like.
No code of yours on the customer's phone, no new data about the customer — category flags only.
Verifier SDK, reference verifier and policy template; integration in weeks, fully remote.

Pilot for verifiers

For wallet providers

The safety feature banks will ask your wallet for.

Context unit as an SDK for Android (iOS to follow), or as an operating-system service.
Protects the user at the moment of consent, without surveillance: category flags, local evaluation, visible to the user, declinable.
Works with OpenID4VP, ISO/IEC 18013-5 proximity flows and the credential formats in the EU architecture.
A capability vector tells verifiers what your platform could observe — absence is never mistaken for inability.

Pilot for wallets

Technical overview

Enough to judge the design. The scoring rules, thresholds and per-platform reliability tables are shared with pilot partners under NDA, not here.

Field	Meaning
`risk_class`	0–3, derived on the device from a fixed set of indicator classes
`flags`	category flags only: voice_call, remote_access, screen_share, cross_device_no_proximity, device_integrity, history — or “not observable”
`issued_at`	timestamp within the consent window
`request_hash`	hash of the presentation request (nonce, transaction data)
`presentation_hash`	hash of the presentation the record belongs to
`channel`	same-device or cross-device, with the proximity-proof result
`user_response`	outcome of the user prompt (confirmed, paused, declined)
`policy_version`	version of the rule set used
`capabilities`	which signal categories this platform could observe
`seal`	signature with the presentation key and/or a platform attestation including the record's hash

// illustrative, field names from schema draft v1
{
  "risk_class": 2,
  "flags": ["voice_call"],
  "issued_at": "2027-03-02T10:41:07Z",
  "request_hash": "sha-256:9K_2A5P…",
  "presentation_hash": "sha-256:Qa7mC…",
  "channel": { "mode": "same_device" },
  "user_response": "confirmed_after_warning",
  "policy_version": "1.0.0",
  "capabilities": ["voice_call", "screen_share",
                   "device_integrity"],
  "seal": { "alg": "ES256", "kid": "presentation-key",
            "platform": "verified" }
}

Non-separable

Same key, same nonce, same response as the presentation. There is no second channel to suppress or misroute.

Fresh and bound

Bound to the verifier's one-time request identifier and to the presentation hash; a copy proves nothing elsewhere.

Capability-aware

A capability vector distinguishes “no signal” from “cannot observe”, so policies stay fair across platforms and OS versions.

Privacy by construction

Evaluated on the device; categories only; no identifiers, numbers, content or location; the person sees the record and can decline the presentation.

Deployment options

Inside the wallet, as an SDK inside the verifier's own app (same-device flow), or as an operating-system service used by both.

Accessible by design

Accessibility services are never counted alone and never produce a category flag of their own, so people who depend on them are not disadvantaged.

OpenID for Verifiable Presentations

Requested as a credential type through DCQL or as a transaction_data element; returned inside the same presentation response, signed with the presentation key.

SD-JWT VC and W3C VC

Carried as a claim in the key-binding part or as an additional credential in the response — no change to the credential formats themselves.

ISO/IEC 18013-5 (mdoc, proximity)

Included in the device-signed data and bound to the session transcript; proximity proofs for cross-device hand-overs are part of the record.

EUDI Architecture Reference Framework

The wallet's capability to produce the record can be signalled through the Wallet Unit Attestation; a specification draft for OpenID4VP is available on request.

OpenID4VPSD-JWT VCISO/IEC 18013-5W3C VCEUDI ARFDigital Credentials API

Replay and relay

Addressed by request binding (nonce, transaction hash) and by proximity proofs for cross-device flows; a relayed QR code without proximity proof becomes a category flag of its own.

Tampering

The seal uses the presentation key and, where available, a platform attestation that includes the record's hash; a modified record fails verification.

Downgrade

The capability vector states what the platform could observe, so a missing flag cannot be passed off as a calm situation.

Measured, not promised

Detection per attack scenario, false-positive rate and latency are measured in every pilot against the partner's own test scenarios and reported in numbers.

What is deliberately not on this pageScoring weights and thresholds, the pattern library behind the risk classes, per-platform signal reliability, and the attacker-lab results. These are trade secrets and are shared under NDA with pilot partners.

Eight to twelve weeks, fully remote, with measured results.

We run a small number of pilots with banks, payment providers and wallet providers in Germany and Italy first. A pilot ends with numbers, not slides: detection per attack scenario, false-positive rate, latency.

Pilot partners get a licence option on the verifier SDK and a say in the specification before it is published.

What a pilot includes

Verifier SDK and reference verifier in your sandbox
Wallet-side demo on Android with the five scam scenarios
Attestation schema v1 and a policy template for your transaction types
Two-day remote integration workshop, weekly status
Final report with measured results from your own test scenarios

Ask for a pilot slot

Slots for Q1 2027 are limited. Technical blueprint, FAQ for fraud teams and a 20-minute remote demo on request.

Made in Lübeck for the European identity wallet.

Calmproof is a product of BuonaLabs UG (haftungsbeschränkt), Lübeck. It is built on the open standards the EU Digital Identity Wallet runs on and is developed fully remote, with Germany and Italy as the first two markets.

The name says what the record is: proof that the person was calm — not under a voice, a remote hand or a borrowed screen — when they said yes.

PatentGerman patent application filed 21 October 2026, 21 claims; international extension within the priority year

StandardsSpecification draft for OpenID4VP; aligned with the EUDI Architecture and Reference Framework

CompanyBuonaLabs UG (haftungsbeschränkt)
Maria-Goeppert-Straße 3, 23562 Lübeck, Germany
Amtsgericht Lübeck, HRB 26385 HL

Read the design before you take the call.

Public documentation for fraud, security and data-protection teams. Everything a first review needs; the details that belong to pilot partners stay under NDA.