Account security

What protects an account and the money on it

Rules written down before the first line of code, and every one of them is a constraint on us rather than a feature we could quietly switch off later. Wallet keys are a separate subject with its own threats, and it has its own page.

Open an account

TOTP Second factor A stolen password on its own moves nothing: payouts require the code from an authenticator app.

0 Card numbers stored The number and CVV are drawn by the issuer in its own frame and are in neither our database nor our logs.

Append-only Ledger Entries are never edited or deleted. A mistake is corrected by a reversing entry, and the history stays whole.

7 days Log retention Logs live a week and are then gone, because data that no longer exists cannot leak.

Getting in, and getting money out

An account needs an email address or a Telegram account. Two-factor authentication is offered at sign-up and takes about thirty seconds to set up: TOTP by RFC 6238, which any authenticator app understands.

It is optional, and what it guards is the front door: with it on, a stolen password alone will not get anyone into the account. It is not a second confirmation on each withdrawal — a session that is already open is not asked again. Switching it on, like changing the password, ends every other session, and that is the lever to pull if you think someone else is inside.

Money notifications go to Telegram, and an account has to be linked to it before it can top up, order a card or subscribe. A person who cannot be told that their money moved is a person using money blindly.

Card data does not pass through us

The card number, the expiry date and the CVV are rendered by the partner issuer, inside the issuer's own frame. They do not travel through Blomo's backend, and they are in neither our database nor our logs.

This is worth stating precisely, because the industry phrase «we store card data securely» usually means the opposite: that it is stored. Ours is not stored at all, and a breach of Blomo cannot hand anyone a card number that was never there.

The ledger cannot be rewritten after the fact

A balance is not a number in a column that something increments. It is the sum over entries, and those entries are append-only: the database itself refuses an update or a delete on them.

That refusal is enforced by the database, not by our code. Even the application, with full write access, cannot alter a posted entry. A mistake is corrected the way accountants have corrected mistakes for centuries — with a reversing entry — and the history of what happened stays intact and auditable.

Every on-chain event is applied exactly once, however many times the network hands it to us. A payment counted twice is as wrong as a payment lost, and idempotency is what stops both.

What we keep, and for how long

Virtual cards need no identity documents at any stage: not at sign-up, not at top-up, not at issue, not at payment. On the ordinary path there is no passport, no selfie, no proof of address and no questionnaire about the source of funds. Incoming funds are screened, though, and Section 6 of the terms sets out what an extended check may ask for when a top-up raises a sanctions or anti-money-laundering question. A physical card is the exception, and the requirement there comes from the partner issuer, not from Blomo.

Logs are kept for seven days and then deleted. The reason is short: data that no longer exists cannot leak, cannot be subpoenaed and cannot be sold by someone who left.

How the system is put together

The application runs without the right to change the database schema: it can work with data and nothing more. Schema changes are made by a separate migration path with its own credentials, so a compromised API cannot drop a table.

The signing service lives apart from the application and answers only a small, fixed set of requests. It has no free-form «send to this address» operation, because a service that accepts a recipient from the caller is a service that pays whoever asks convincingly enough.

At a glance

Two-factor authentication: TOTP by RFC 6238, offered at sign-up, protects the sign-in
Card number and CVV: Rendered by the issuer, never through Blomo's backend
Ledger entries: Never edited or deleted — corrections are reversing entries
On-chain events: Applied once, however many times they arrive
Money notifications: Telegram, and a linked account is required before money moves
Logs: Kept for seven days, then deleted
Identity documents: None for virtual cards, at any stage
Schema changes from the app: Impossible — the app has no rights to alter the database

FAQ

Questions people actually ask

Is two-factor authentication mandatory?

It is offered at sign-up and stays optional. With it on, a stolen password alone will not get anyone into the account; it is a check at sign-in, not a second confirmation on each withdrawal. TOTP by RFC 6238, so any authenticator app works.

Does Blomo store card numbers?

No. The number, expiry and CVV are rendered by the partner issuer inside its own frame and never pass through Blomo's backend. They are in neither our database nor our logs.

Can a balance be edited by hand?

No. Balances are sums over ledger entries, and the database refuses updates and deletions on those entries — the application itself cannot alter a posted one. Corrections are made with a reversing entry, so the history stays complete.

What happens if the same deposit arrives twice?

It is credited once. Every on-chain event carries a reference that is accepted only once, so repeated delivery from the network changes nothing.

How long are logs kept?

Seven days, then they are deleted. Data that no longer exists cannot leak.

Does any of this protect Blomo Wallet?

Blomo Wallet is a different thing with a different threat model: it is non-custodial, its key is created and used on your device, and Blomo cannot move funds from it. That subject has its own page.

Open an account and see for yourself

Email or Telegram, no documents, and two-factor authentication set up in about thirty seconds.