How we protect your claims and your money

What we will never ask you for

This is the most useful thing on this page, so it goes first. We will never ask for:

• Your full card number, or the CVV on the back
• Your full bank account number or IBAN
• Your online banking username or password
• A crypto private key or recovery phrase — for any reason, ever
• A one-time code we did not just prompt you for on screen

What we do ask for is the last four digits of a card or account, and for crypto a public receiving address. Neither can move money on its own. The database has no column capable of holding anything more, and the address field actively rejects input that looks like a recovery phrase rather than storing it.

If anyone contacts you claiming to be us and asks for the items above, it is not us. Forward it to support@securerefund.online.

Your balance is a ledger, not a number

We do not store your balance in a field that gets overwritten. Every movement — money recovered, our fee, a withdrawal, a withdrawal returned — is a separate permanent entry, and the balance is their sum. Nothing is ever edited or deleted.

That matters because a balance held as a single mutable number can be corrupted by a lost update or a retried request, and afterwards nobody can say what the right figure was. Here, any balance can be reconstructed line by line, and you can read the same history we do on your wallet page.

There is no way for an account — yours or anyone else's — to write a credit. The permission to insert ledger entries is not granted to signed-in users at all; entries are created only by the system when a claim is actually settled.

Withdrawals

• Funds are reserved the instant you request a withdrawal, so the same money cannot be sent twice.
• Two withdrawals submitted at the same moment are serialised, so a race between two browser tabs cannot overdraw the balance.
• A withdrawal can only go to a destination attached to your own account, and only you can request one against your balance.
• If a payout fails, the money returns as a visible reversal — the original debit stays in the history rather than being erased.

Your data is separated at the database, not just the app

Every table enforces row-level security. A query for another claimant's claim, balance or payout destination returns nothing — not an error page from the application, but an empty result from the database itself. That holds even if the application layer were bypassed entirely, which is the failure mode most breaches actually take.

Policies are written per operation, so being able to read something never implies being able to change it. Administrative fields on a claim — the recovered amount, the assigned handler, the outcome — cannot be written by a claimant at all.

Documents are private by default

Evidence is stored in a private bucket, namespaced by user and by claim, and served only through short-lived signed links. Only you and the case handler assigned to your claim can open a file. Once a claim has been filed with a provider, its evidence is frozen so that what we sent stays reconstructable.

Staff access costs a second factor

Reading a proof-of-identity document, viewing the audit log, adjusting a balance, or changing anyone's permissions all require a member of staff to have passed two-factor authentication in that session. Stealing a staff password, or getting into a staff mailbox, is not by itself enough — the database checks the session's assurance level before returning or writing the rows.

Everything important is written down

Every change to a claim, a balance, a payout, a permission or an outcome is appended to an audit trail recording who did it and when. It cannot be edited or deleted through the application by anyone, including staff. If you ever need to know what happened to your money and when, there is a record.

Your own account

You can sign in with a one-time code sent to your email, which means there is no password to leak. If you prefer a password you can set one, and either way we strongly recommend adding an authenticator app from your security settings — it is the single most effective thing you can do to protect a balance. Reset emails never reveal whether an address has an account.

Reporting a vulnerability

If you think you have found a security problem, email support@securerefund.online with enough detail to reproduce it. Please give us a reasonable window to fix it before publishing. We will not pursue you for testing carried out in good faith without degrading the service or touching other people's data or funds.

What we are still working on

Being straight about the gaps: a per-device session list is not available yet, server-side virus scanning of uploads is not in place, the withdrawal concurrency guard has not been load-tested under real traffic, and the service has not yet had an independent penetration test or a financial-controls audit. All of these are planned before the service handles money at scale.