Trust model

Authority that stays with the human—and the bank.

How Keyra separates authentication from authorization, binds transactions, and keeps recovery from becoming a soft backdoor.

Talk to Keyra

Familiar principle

You already deploy hardware authentication.

Keyra extends the principle to the card estate.

Bank today

Session auth
  1. Employee
  2. TOTP / hardware authenticator
  3. Authentication event
  4. Bank IAM
  5. Access granted

Keyra-enabled authority

Bound approval
  1. Customer / Employee / Vendor
  2. Bank-issued Keyra card
  3. Hardware-rooted cryptographic approval
  4. Bank authorization infrastructure
  5. Action authorized

TOTP answers: Who is present?

Keyra transaction binding can also answer: What did they authorize?

Keyra is not “TOTP on a bank card.” It is a firmware-level trust utility that can bind approval to a specific instruction.

Authentication vs authorization

Authentication is not the end state.

  1. Who are you?
  2. Can we trust the credential?
  3. Did you authorize this exact action?

Banks do not only need confidence about who entered a session. They need evidence of who authorized the consequential financial instruction.

Transaction binding

What the customer sees is what gets signed.

Authorization request

Action
Outbound wire
Amount
$250,000.00
Beneficiary
XYZ CORPORATION
Originating account
•••• 8842
  1. Authorization request
  2. Card presented
  3. Customer reviews
  4. Customer approves
  5. Card signs
  6. Bank verifies
  7. Authorized
Awaiting review

Transaction binding covers the specific instruction—not merely the login session.

Deterministic evidence

From session logs to instruction-bound proof.

Stop asking “Did something happen?” Start asking “What credential approved what instruction?”

Traditional

Login log

  • Session opened
  • MFA passed
  • Channel authenticated

No record of the specific instruction that was approved.

Keyra

Transaction-bound authorization record

Customer reference
CUST-4417-2098
Credential reference
CRED-8F21-A004
Action
OUTBOUND_WIRE
Amount
250,000.00 USD
Destination
XYZ CORPORATION
Timestamp
2026-08-29T14:02:11Z
Challenge
NONCE-7C4E…
Signature verification
VALID
Credential status
ACTIVE AT TIME OF USE
Policy applied
WIRE > 100K — HUMAN AUTHORITY
Decision
APPROVED
Audit reference
AUD-2026-0829-118

Verifiable after the event.

Cryptographic evidence does not independently establish subjective intent or resolve every legal dispute.

Threat model

A credible security proposition states its limits.

Hardware credential

Strongly addressed by hardware credential

  • Credential phishing
  • OTP interception
  • SIM swap
  • Certain credential replay
  • Verifier credential theft

Transaction binding

Improved through transaction binding

  • In-session transaction manipulation
  • Beneficiary manipulation
  • Instruction alteration

Limits

Not solved by hardware alone

  • Authorized push-payment scams
  • Social engineering with knowing approval
  • Physical coercion
  • Insider collusion

Complementary credentials

This complements passkeys. It does not compete with them.

Passkey

Everyday login
  • Phishing-resistant
  • Platform/device recovery
  • Excellent everyday login experience

Keyra trust card

High-consequence authority
  • Hardware credential
  • Bound to physical card
  • Bank-issued
  • Can support transaction-bound authorization
  • Off-device physical credential

Use passkeys for everyday login. Reserve hardware authority for events where consequence or evidence requirements justify it.

Selective disclosure

Answer the question. Disclose nothing else.

Service asks

“Is this person over 18?”

Conventional

Upload full identity document

Keyra credential model

Signed assertion that condition is satisfied — no unnecessary DOB exposure.

  • Minimum necessary disclosure
  • Customer consent
  • Purpose limitation
  • Cryptographic verification
  • Auditability

AI authority

Human authority

AI can act. Humans must retain authority.

Authorization simulation

Step 1 / 5
  1. AI agent“Transfer $50,000.”
  2. SystemHuman authorization required.
  3. CustomerReviews amount, destination, action.
  4. Keyra cardTap to authorize.
  5. ResultAUTHORIZED

Bank policy

The bank sets the authority policy. Not the AI platform.

Tier 1 — Observe

Agent can read / analyze / recommend.

Tier 2 — Act within limits

Agent acts inside a pre-authorized envelope.

Tier 3 — Escalate to human

Action exceeds authority envelope. Keyra approval required.

Tier 4 — Always human

Bank-defined categories always require explicit human authorization.

Recovery

Recovery is where trust chains break.

Card temporarily mislaid

Pause credential.

Card lost or stolen

Revoke credential with card.

Replacement issued

New card. New key pair. Nothing copied from old key.

Recovery without card

Bank re-verifies customer using bank-controlled recovery process.

The effective assurance level is set by the weakest recovery path.