Security

A second device, not a second code

Enrolment is the moment a phone becomes yours to approve with. The Swiss Vault Access app generates a key pair inside the phone's own hardware and registers only the public half with us. The private half cannot be exported, and it is created so that every use of it requires the phone's biometric unlock. That gate has so far been shown only in refusal: in the Keystore trial run for this project, a key created this way refused to sign at all without a fresh unlock. That a successful unlock then yields a signature the server can verify is designed, and still has to be demonstrated on a real handset.

Approving a payment means signing a challenge with that key. The server issues a single-use number that expires after ninety seconds, the app signs it after you unlock the phone, and the server checks the signature against the public key you enrolled. The app shows the amount, the device and the place the request came from, and asks you to tap the one number of three that also appears on the web page. That last step exists because a prompt with a single Approve button trains people to tap it without reading.

A retyped code is weaker because it travels. It can be read aloud to someone claiming to be the bank, typed into a page that only looks like ours, or forwarded in a message. A signature cannot be handed over in any of those ways: it is produced by a key that never leaves the device, and it is valid only for the one request it was made for.

Assurance levels

Not every action needs the same proof. Swiss Vault sorts them into four levels. L0 is a valid session, and permits reading a balance and a transaction history. L1 adds a browser we recognise, and permits statements and documents.

L2 requires a signed, number-matched approval on the enrolled phone, and is what a withdrawal or a change of limit needs. L3 is L2 twice over, separated by a twenty-four hour cooling period, and is reserved for the actions an attacker would want first: adding a beneficiary, enrolling another device, or turning multi-factor approval off.

Raising the level is what a step-up prompt is. Nothing is being re-checked for its own sake; the action you asked for sits at a level above the one your session currently holds, and the prompt is how the session gets there. The required level is declared on each operation rather than decided inside it, so it can be read off the code and tested.

A ledger you can check

A balance here is not a number that gets edited. Money moves by writing a journal entry whose debits and credits sum to zero, against real internal accounts for funding, settlement and fees. An entry that does not balance cannot be written, so a balance is always the sum of the entries behind it rather than a figure that was set separately.

Each entry also stores a hash of the entry before it, forming a chain from the first entry onwards. Altering one historic row does not quietly change one row: it breaks the hash of every entry recorded after it.

This is meant to be demonstrable rather than asserted. Once the ledger and its verifier are built, a posted amount can be changed directly in the database and the verifier run against it: it will walk the chain and name the exact entry where it first stops matching. Neither exists yet, so there is nothing on this site today to tamper with. The demonstration is designed in from the start, because a claim about immutability that can be shown is worth more than one that has to be believed.

Risk that explains itself

A payment is scored against that customer's own baseline, not against a fixed threshold shared by everyone. The signals include how far the amount sits from their rolling history, whether the hour is one they usually transact in, whether the device or the beneficiary is new, how much has moved recently, the distance between consecutive sign-ins against the time between them, and a large movement after a long dormancy. A new customer has no baseline, so the first transactions are judged under conservative fixed defaults until one exists.

Each signal is a separate rule that returns a score and a reason in words. Every decision is written to the audit record with its full list of reasons, including the payments that were allowed through. An officer who is asked why a payment was stopped, or why one was not, has an answer on record rather than a score with no account of itself.

A payment held for review is held. The funds do not move, a case is opened, and a person decides. The alternative, letting the payment through while raising an alert somebody may read later, is the outcome this design exists to avoid.

Fail closed

If the risk engine cannot be reached, payments do not default to allowed. They queue for review, and stay queued until they can be scored or a person decides them. The same rule governs any unresolved doubt in a money operation: funds are held, never posted.

A control that fails open is worse than no control at all. It produces confidence without protection, and it does so most reliably at the moment the system is under strain, which is exactly when the protection was supposed to matter. A queue is visible and can be worked through; a silent gap cannot.

What we do not do

There are no payment rails behind deposits and withdrawals. No funding, settlement or transfer exists in the system today, and when it is built it will run through internal accounts only, not a live provider.

Identity documents are collected and stored, and identity verification is simulated: the check runs against an interface that returns configurable outcomes rather than calling a live identity-verification provider, because connecting one is out of scope for this stage of the project. There is no real sanctions data either; the watchlist is synthetic, written with deliberate near-misses so that screening has something to get right and something to get wrong.

The full statement of what this project is, and what it is not, is on the legal page.