Payment security

A valid signature is not an authorization

How the largest payout attacks of 2025–2026 got past controls — and what actually stops them.

Sergei Vasiliev, Uravin d.o.o. · 24 October 2026 · 7 min read

For years, payment security was built around one question: is this command authentic? Is it signed, did it come through the right channel, from a known system, with a valid token?

The largest payout losses of the last eighteen months share an uncomfortable feature: the answer to that question was “yes”. The commands were signed. They came from inside. They passed the normal authorization flow. And the money left anyway.

Below are four patterns from public incidents, why existing controls let them through, and the controls that close each gap.

1. A compromised backend sends commands the system trusts

What happened. On 24 September 2026, about $387.5 million was withdrawn from the Bitget exchange. According to the company’s CEO, private keys and cold wallets were not compromised. The attacker gained access to a critical backend system in the wallet infrastructure, spoofed transaction data and pushed the forged withdrawals through the exchange’s own authorization process.

Why controls missed it. The authorization layer trusted what the backend told it. Once the backend was compromised, every downstream check confirmed a lie: the request was well-formed, properly signed by an internal service and within the expected flow.

What closes it. An independent verifier that does not share the backend’s trust. It holds its own keys and its own view of state, and it re-checks every outgoing command against facts the backend cannot rewrite: the approved record the payout claims to pay, limits and the current signed balance. A compromised backend can request a payout; it should not be able to approve one.

2. Valid credentials at a provider become fraudulent transfers

What happened. In July 2025, attackers used valid client credentials at C&M Software, a technology provider connecting institutions to Brazil’s Pix instant-payment system, to create and sign fraudulent transfers out of several institutions. Losses were reported at R$800 million or more. In August 2025 a similar attack went through another provider, Sinqia. Brazil’s central bank then tightened the rules for the whole sector: transfer caps for unauthorized participants, stricter governance and capital requirements for technology providers.

Why controls missed it. The credentials were real. From the payment system’s point of view, an authorized participant was sending properly signed messages. Nothing looked forged, because nothing technically was.

What closes it. Treat a valid credential as identity, not permission. Every outgoing transfer should be matched against something that exists independently of the channel: an approved business record (a loan, an invoice, a merchant settlement), a beneficiary rule, a per-participant limit. If the transfer cannot be tied to an approved record, it does not move automatically.

3. Stolen partner and API credentials drive payouts past checks

What happened. On 9 October 2026, India’s CERT-In warned NBFCs, fintechs, payment service providers and wallet operators about attacks in which stolen payment-aggregator and partner-bank API credentials were used to push payouts that bypassed KYC, loan-sanction and authorization checks. Media reported fictitious loan references, payments above prescribed limits and transfers spread across many beneficiary accounts.

What CERT-In recommended is worth quoting almost verbatim, because it is a design specification:

• maker-checker approval for fund transfers, with cryptographically linked stages;
• validating every payout against sanctioned records and rejecting invalid references;
• per-transaction and daily limits enforced at the API level;
• beneficiary verification and real-time monitoring;
• centralized logging with long retention.

What closes it. Exactly that list — implemented outside the system whose credentials can be stolen. If the same backend that initiates a payout also performs the “checker” step, a stolen credential defeats both.

4. Uncertainty becomes a second payment

The pattern. A payout is reserved, the connection to the bank or provider drops, and the outcome is unknown. The common reflex — retry — can turn one payment into two. A related failure mode: a deployment or configuration change silently disables a check, and the system keeps processing as if everything were fine.

Why controls miss it. Most systems are built to keep money flowing. When a component is unavailable, they fail open: the payment proceeds and reconciliation happens later, if at all.

What closes it. Fail-closed by default. If a key, a proof or an independent confirmation is missing, the operation does not proceed automatically — it goes to review. An unknown outcome triggers reconciliation of the original operation, never a blind retry. Versions only move forward, so a replayed or rolled-back request is rejected rather than executed again.

What these incidents have in common

None of them required breaking cryptography. Each one exploited the same assumption:

If a command is authentic, it must be allowed.

Authenticity, permission and finality are three different facts:

1. Authenticity — who sent this command, and was it changed?
2. Permission — is this operation allowed by policy and by the current state?
3. Finality — has the bank or provider actually confirmed the result?

Most stacks check the first and assume the other two.

A practical checklist

You can apply this with or without any vendor:

• Is there a verification step for outgoing payouts that runs outside the backend that initiates them, with its own keys?
• Is every payout matched against an approved record, not just a valid token?
• Are limits enforced at the API boundary, not only in the UI or the business logic?
• Are maker and checker cryptographically separated, so one stolen credential cannot do both?
• On an unknown outcome, does the system reconcile rather than retry?
• When a check is unavailable, does the payout stop (fail-closed) or continue?
• Is the decision log append-only and tamper-evident, so an insider cannot rewrite history?
• For data that must stay confidential for years: is there a plan for post-quantum signatures and key exchange, given that traffic captured today can be decrypted later?

If several boxes stay empty, the gap is not theoretical — it is the exact gap the incidents above went through.

What we are building

At Uravin we are building AIGIS, an isolated verification layer that sits between a backend and its payment gateway and implements the checks above: signature against a registry of trusted keys, a match against the signed balance snapshot and the approved record, policy limits, replay protection, fail-closed decisions and an append-only, hash-chained audit log. It is currently a release candidate, and we are working with a small number of pilot partners.