PIX MED 2.0 for Brazilian iGaming: Where Reconciliation Breaks

Pix is irrevocable on the SPI ledger and reversible on the operator's. Since 2 February 2026, every Pix deposit a Brazilian iGaming operator credits to a player's wallet sits inside an 80-day window during which a MED 2.0 claim can pull funds back out of the operator's bank account, regardless of what the player did with the credit between day 0 and day 60. The original SPI settlement is final and does not move. The merchant's net position does. That asymmetry is what breaks reconciliation in operator stacks built on the assumption that "instant" and "settled" mean the same thing about a Pix deposit. This article is the operator-side audit: what desyncs in the wallet ledger when a MED reversal lands sixty days after a player has cashed out, what same-CPF means inside one cashier session, what the PSP webhook contract has to carry, and what evidence wins a defense inside the 7-day analysis window. The legal-firm coverage of Resolução 493 has been extensive. The reconciliation playbook has not.

How MED 2.0 inverts Pix irrevocability

Pix is real-time gross settlement on the BACEN-operated SPI infrastructure. Once an SPI message confirms a transfer, the entry is final and irrevocable on the central bank's ledger, per the World Bank's Pix case study. The operator's PSP receives the credit, the operator's bank balance moves, the operator credits the player's wallet. Through 2025, deposits looked final from the operator's view because the only reversal channel was the original MED, and the original MED's recovery rate sat below 7 percent. The economic incentive to ignore MED filings was strong enough that most iGaming MIDs treated the Pix deposit ledger as immutable.

MED 2.0, introduced by Resolução BCB nº 493 of 28 August 2025 and mandatory across all Pix participants from 2 February 2026, raised that recovery target to roughly 80 percent by tracing funds across up to five subsequent accounts rather than blocking only the first receiver, per the ABBC technical brief on Resolução 493 and VAAS' implementation guide. Voluntary use opened 23 November 2025; the mandatory cutover landed 2 February 2026. Supervisory penalties begin biting non-compliant institutions from May 2026, per ClearingPost's coverage of the rollout.

What MED 2.0 does mechanically, and the part legal-firm coverage skips, is not reverse the original Pix transaction. The MED is a separate Pix in the opposite direction, executed by the receiver's institution against the receiver's account and credited back to the original sender. The original SPI message stays final on the BACEN ledger. The receiver's bank balance moves. For an iGaming operator whose receiver-side account is the merchant settlement account at its PSP, the consequence is straight asymmetry. The original Pix deposit settled cleanly on day 0, the PSP statement and the operator's wallet ledger were both correct at that moment, and the day-0 wallet credit was used between day 0 and day 60 by the player who gambled it, lost some, won some, and likely withdrew net winnings to their own CPF-bound Pix key. On day 60, the original sender (the player, or someone using the player's account credentials) files a MED claim. The 80-day filing window opens at the day-0 deposit timestamp. MED 2.0 traces through up to five hops if the operator's PSP forwarded the funds elsewhere; in typical iGaming PSP topology there is a single hop from the player's PIX to the operator's settlement account, so the trace lands at the operator's PSP. The PSP, on instruction from the player's institution after a 7-day analysis, debits the operator's settlement account for the disputed amount and emits a return-Pix to the player's institution.

The original deposit is not unwound. The MED-driven debit is a fresh transaction with its own end-to-end ID and its own settlement timestamp. Reconciliation systems that key on the original deposit's e2e ID will not see the deduction unless they are explicitly listening for the MED event class.

The asymmetry compounds because Pix is roughly 90 percent of deposit traffic across Brazilian iGaming overall, and around 96 percent on SPA-licensed regulated books specifically, per Pay4Fun's market commentary and KYCAid's payment-blocking analysis. Lei 14.790 excluded credit cards and crypto from the regulated market and Portaria SPA/MF 615/2024 narrowed accepted methods to electronic transfers at Central Bank-authorized institutions, per the iGamingBusiness Brazil betting payment guide. With the SPA's enforcement push from 1 January 2026, more than 90 percent of deposit liability on a SPA-licensed book sits inside the 80-day MED window at any given moment.

The wallet-ledger desync most operators ship in production has the bug pattern below. A typical wallet ledger commits a deposit at PSP-webhook receipt as final state, with no event type for "post-settlement reversal originating from a counterparty's institution sixty days later." When the MED reversal arrives, the ledger has three consecutive failures. The operator's bank balance is short the disputed amount because the PSP debited the settlement account. The wallet credit is still spent because the player gambled or withdrew the funds during the 60-day window. The pagador CPF on the original deposit was the registered player's, but the MED claim was filed by a counterparty using the same CPF, which under Lei 14.790's same-CPF rule is the legally identical entity but not necessarily the same person at the keyboard.

The architectural fix that ships clean is a separate external_disputes table that does not touch the player wallet. The MED reversal is recorded as a merchant-borne loss. The wallet credit from day 0 stays on the player's books. The operator's general ledger absorbs the debit through a contra-revenue or chargeback-loss line. The SPA reports continue to reflect the day-0 state truthfully because the player's wallet did not change retroactively.

CREATE TABLE deposit_events (
  id              BIGSERIAL PRIMARY KEY,
  player_id       BIGINT NOT NULL,
  amount_centavos BIGINT NOT NULL,
  occurred_at     TIMESTAMPTZ NOT NULL,
  e2e_id          TEXT NOT NULL UNIQUE,        -- BACEN end-to-end ID
  pagador_cpf     TEXT NOT NULL,               -- payer CPF from PIX payload
  status          TEXT NOT NULL,               -- 'settled' | 'med_disputed' | 'med_reversed'
  med_filed_at    TIMESTAMPTZ NULL,
  med_resolved_at TIMESTAMPTZ NULL
);
 
CREATE TABLE external_disputes (
  id                BIGSERIAL PRIMARY KEY,
  deposit_event_id  BIGINT NOT NULL REFERENCES deposit_events(id),
  med_case_id       TEXT NOT NULL UNIQUE,
  reversal_e2e_id   TEXT NULL,
  amount_centavos   BIGINT NOT NULL,
  filed_at          TIMESTAMPTZ NOT NULL,
  block_starts_at   TIMESTAMPTZ NOT NULL,      -- 72-hour precautionary block start
  resolution        TEXT NULL,                  -- 'reversed' | 'released'
  resolved_at       TIMESTAMPTZ NULL
);

The wallet ledger reads wallet_events only and stays uninvolved in MED reconciliation. The bank-reconciliation pipeline reads deposit_events joined to external_disputes. The two are intentionally separate. The CFO query against bank-side debits for a period is one line:

SELECT SUM(d.amount_centavos) AS gross_med_loss
FROM external_disputes d
WHERE d.resolution = 'reversed'
  AND d.resolved_at >= :period_start
  AND d.resolved_at <  :period_end;

The pattern that fails at audit is the reverse: operators who debit the player's wallet for the MED amount, send the player a notification of the deduction, and then face an SPA inquiry when the player files a complaint about an unjustified balance reduction. Under Lei 14.790's player-protection framing, the operator cannot reach into the player's wallet to pay an external dispute it has no evidence the player caused. The same-CPF rule means the funds came from the player's own legally bound account. A downstream fraud allegation against the player's bank does not retroactively unwind the operator's contractual relationship with that player.

Same-CPF and the one-session CPF lookup

Lei 14.790/2023 plus Portaria SPA/MF nº 615/2024 narrow accepted payment methods to electronic transfers (Pix, TED, debit) at Central Bank-authorized institutions — the credit-card-ban migration playbook covers the cashier-side rebuild that left the recurring-deposit cohort exposed. Portaria SPA/MF nº 722 and the broader compliance package require strict 1:1 CPF matching: the depositor's CPF on the incoming Pix payload must equal the registered player's KYC-verified CPF, per KYCAid's payment-blocking guide. Mismatches must reject the deposit at the gateway level before any wallet credit. Withdrawals must go to a Pix key bound to the player's CPF in the DICT, the BACEN-operated key directory. Players may register up to three deposit accounts at authorized institutions, per KYCAid's Brazil betting compliance guide.

The cashier engineering implication is that the cross-check has to happen synchronously inside the deposit-webhook handler, before the wallet credit. Operators who persist the wallet credit first and queue the cross-check asynchronously have two compounding problems. The credit may be visible to the player and bet through before the mismatch is caught, requiring a wallet unwind that the SPA's player-protection rules make awkward. The audit log shows wallet credit before identity check, which is the exact non-compliance pattern the regulator's reporting cycle is designed to surface.

The synchronous cross-check at deposit-webhook receipt is straightforward. The PIX webhook from the operator's PSP carries the pagador.cpf field. The wallet handler reads the registered KYC CPF for the player from the canonical KYC profile, not a cached hash and not a registration-time snapshot. The two must match exactly:

def on_pix_webhook(payload):
    player = lookup_player(payload.merchant_order_id)
    kyc_cpf = canonical_kyc_cpf(player.id)         # canonical, not cache
    if payload.pagador.cpf != kyc_cpf:
        reject_deposit(payload, reason="cpf_mismatch")
        return
    deposit = persist_deposit(
        player_id=player.id,
        amount_centavos=payload.amount,
        e2e_id=payload.endToEndId,
        pagador_cpf=payload.pagador.cpf,
        status="settled",
    )
    wallet_credit(player.id, payload.amount, source=deposit.id)

The reverse path on a withdrawal request:

def on_payout_request(player_id, amount, pix_key):
    kyc_cpf = canonical_kyc_cpf(player_id)
    cpf_at_key = dict_resolve(pix_key)              # BACEN DICT lookup
    if cpf_at_key != kyc_cpf:
        reject_payout(reason="key_cpf_mismatch")
        return
    if pix_key not in registered_keys(player_id):
        reject_payout(reason="key_not_registered")
        return
    initiate_pix_payout(pix_key, amount)

The "one session" qualifier matters because of how the canonical CPF can rotate. KYC re-verification, manual override after a name correction, or the player updating their profile against an updated Receita Federal record all rewrite the canonical CPF. An operator that snapshotted the CPF at registration and trusts that hash on subsequent transactions has a stale-cache bug latent in production. The same player, post-KYC update, will fail the cross-check on a deposit that should have cleared. The bug surfaces as a flood of false-mismatch rejections after a routine KYC re-run, and the operator's first instinct is usually to widen the comparison rather than to fix the cache. Widening the comparison breaks the 1:1 rule the SPA inspects against.

The MED defense argument also depends on the synchronous cross-check evidence. If the operator can show, in the audit log, that the deposit's pagador.cpf matched the canonical KYC CPF at the moment of credit, the operator's evidence package is materially stronger when the MED claim arrives sixty days later. The same-CPF chain of custody is the load-bearing fact in MED defense for iGaming, because the alternative reading (the depositor was not the registered player) is structurally barred by SPA rules. The player and the depositor are the same legal person under the regulated framework. The cross-check evidence is what proves it.

The CPF-lookup architecture has to satisfy three constraints at once. Synchronous to the deposit webhook. Against the canonical KYC profile. With a permanent audit trail tying each deposit row to the KYC version current at credit time. Operators who built the CPF check as an asynchronous side-process or against a cached profile are exposed on both compliance and MED defense fronts; there is no second chance to prove same-CPF after the fact.

What the PSP must emit on a MED reversal

The deposit-limit subsystem, the wallet ledger, and the MED dispute pipeline are all downstream of the PSP. They count and react to events the PSP emits. In the Brazilian iGaming PSP market, that PSP is most often EBANX, Pay4Fun, AstroPay, PayRetailers, or a domestic alternative depending on operator size and licensing posture. Each emits Pix webhooks on a slightly different shape, and the MED 2.0 cutover is the moment to lock the contract on what fields and what event types you require.

Five fields are non-negotiable for clean reconciliation. The end-to-end ID is the BACEN-issued unique identifier for the Pix transaction; it survives across operator, PSP, and recipient layers and is the only stable key for joining a deposit on day 0 to its MED reversal on day 60. The settlement timestamp is the moment the SPI confirmed the original transfer, not the moment the operator's webhook handler ran; the 80-day filing window starts at the SPI timestamp, and operators counting from webhook-receipt time miscompute the window by minutes to hours. The final amount in centavos is what reached the merchant settlement account after any PSP fee deduction. The pagador CPF is the load-bearing field for the same-CPF cross-check and for MED defense. The final status field needs distinct event values for SETTLED, PRECAUTIONARY_HOLD (the 72-hour automatic block under MED 2.0), MED_DISPUTED (the 7-day analysis is open), MED_REVERSED (analysis confirmed and the funds debited the merchant), MED_RELEASED (analysis cleared the merchant), and VOLUNTARY_REVERSED for operator-initiated refunds, distinct from MED so the accounting treatment differs.

The MED-specific event a clean webhook contract carries:

{
  "event": "med.reversal_executed",
  "occurred_at": "2026-04-08T14:23:00Z",
  "original_e2e_id": "E12345678202604081200a1b2c3d4e5f6",
  "reversal_e2e_id": "E98765432202604081423b2c3d4e5f6a1",
  "amount_centavos": 50000,
  "settlement_account_debit_at": "2026-04-08T14:23:00Z",
  "med_case_id": "MED-2026-04-XYZ123",
  "filed_at": "2026-02-08T10:00:00Z",
  "stage": "after_analysis",
  "evidence_submitted": true,
  "outcome_reason": "fraud_confirmed_by_payer_psp"
}

The fields the operator leans on during reconciliation are predictable. original_e2e_id finds the day-0 deposit row. settlement_account_debit_at buckets the loss into the correct accounting period; it is rarely the same as occurred_at for partner PSPs because settlement-account batching can lag MED resolution by hours to days. med_case_id cross-references against any defense submission. outcome_reason sizes the policy response across cohorts of disputes.

EBANX automates the MED lifecycle for merchants on its platform, per its MED Pix Overview docs. Merchants receive an API notification when the MED refund executes and the corresponding amount is deducted from settlement, with no additional fee beyond the refunded amount. Operators on AstroPay, PayRetailers, Nuvei, Adyen, or direct BACEN integrations get more variable webhook coverage, and a polling layer against the PSP's dispute API is sometimes required to detect MED state transitions reliably. IXOPAY, Solidgate, and Primer as orchestration layers pass through the underlying PSP's events, and the orchestrator's normalization quality varies by integration depth. Paysafe's Latin American footprint includes Brazil and the same considerations apply.

The breaking webhook contract pattern is the one many operator integrations shipped through 2025: events emitted only on SETTLED, no event for REVERSED. Operators relying on this had no programmatic way to detect MED reversals and reconciled by manually pulling PSP statements monthly. With MED 2.0's projected uplift in recovery to roughly 80 percent of disputed amounts, the volume of MED events at iGaming MIDs scales enough to make manual reconciliation untenable. The CAIXA-side data point is suggestive: MED disputes hitting lottery and betting outlets through the federal bank's rail prompted five separate risk-mitigation measures across February and March 2026, with FEBRALOT and state unions raising the immediate-debit and 7-day-block patterns as operationally untenable on the lottery side. Commercial PSPs hit the same volume curve.

The clean contract requirements the operator needs in writing from the PSP cover four points. Idempotency keyed on e2e_id for both deposit and reversal events; webhook retries during a PSP outage will replay events, and double-counting a reversal compounds the loss. A distinct event type for MED reversals, separate from voluntary refund events, because the accounting and SPA-reporting treatments differ. Settlement-account debit timestamp included as its own field, because the operator's books take the loss when the debit clears the settlement account, which can lag the MED resolution. The MED case ID, mandatorily, for cross-referencing with the defense submission and the PSP statement. Operators integrating through EBANX inherit much of this contract by default, per EBANX's PIX refund flow documentation. Operators on direct-to-acquirer or direct-to-bank Pix integrations have to specify the contract in writing, often as a rider to the master service agreement.

The 7-day analysis window and what evidence clears

The end-to-end MED 2.0 timeline runs roughly 11 days from filing to refund execution: under 30 minutes to open the infraction notification per the BACEN Pix Time Manual, up to 7 days for the receiver's institution to analyze the dispute, and up to 96 hours after the analysis to execute the refund, per VAAS' implementation guide and the BACEN MED guide. The substantive defense window for the operator is the 7-day analysis. After that, the institution's decision is final and the funds debit the operator's settlement account.

What evidence clears a MED filing on an iGaming book, in order of weight on the analysis, falls into three patterns. The same-CPF chain of custody is the strongest. The day-0 deposit's pagador.cpf matches the registered player's KYC CPF; the day-N withdrawal, if any, routed to a Pix key resolved to the same CPF in DICT. Inside Lei 14.790's framing, the depositor and the recipient are the same legal entity. A MED claim that alleges the player was a fraud victim is structurally weak when the funds were transferred between accounts the same CPF controls.

The player's session fingerprint at deposit time is the second pattern. Device, IP geolocation, time-on-account, and prior deposit history. A player with six months of book balance and consistent location data is a meaningfully different defense profile than a fresh account that deposited and withdrew within 48 hours. The PSP fraud team and the receiver-institution analyst both look for the latter shape, and that shape correlates with successful MED filings.

The bet log between deposit and withdrawal is the third pattern. Actual gambling activity proves the deposit was consumed for its stated purpose. A R$500 deposit followed by 200 wagers totaling R$1,800 in turnover, regardless of net outcome, is gambling activity. A R$500 deposit followed immediately by a R$500 withdrawal is the pattern that reads as money-movement, not gambling, and is the failure shape that motivated MED 2.0's multi-hop tracking in the first place.

What rarely works as standalone defense is arguing that the original Pix was irrevocable. The original transaction was final on the SPI ledger; that fact is not in dispute. The MED reversal is a separate transaction, not an unwind. PSP defenses on iGaming MIDs that lean on "the original Pix was settled" misread the MED mechanics and lose the analysis.

The 72-hour precautionary block under MED 2.0 means that on filing, the disputed amount is held immediately on the receiver-institution side, before the analysis even begins. For an operator's bank balance, the practical effect is that the funds disappear from available balance within hours of a filing, and the operator has 7 days of analysis plus 96 hours of refund execution to either present cleared evidence or absorb the loss. The 72-hour block does not lift on insufficient evidence; it converts to a confirmed reversal at the analysis decision. The majority of MED filings denied on the merchant side are denied because the funds are no longer in the receiving account by the time the analyst checks, per Yogonet's reporting on the lottery-side dispute volume; for an iGaming operator at scale, where settlement balances do not run thin, that escape valve does not apply. The funds will be there.

CAIXA, the federal bank exposed to high MED dispute volume from FEBRALOT-affiliated outlets, published five risk-mitigation measures across February and March 2026: a dedicated defense workflow with specialized staff, QR-code validity reduced to 10 minutes, payer identification mandatory on PIX transactions, suspension of PIX Withdrawal and PIX Change features (both abused as money-movement vehicles), and conditional transaction completion against payer ID. Most of those mitigations sit on CAIXA's side. The operator-side equivalent for iGaming books is to invest the same work in defense workflows and identity binding before the 7-day analysis window opens.

The silent pattern through Q1 2026 was that some PSPs serving iGaming MIDs defaulted to "no defense" on MED filings to meet internal SLAs, treating each filing as a settle-by-default. With supervisory penalties biting from May 2026, that posture is no longer commercially or supervisorily safe. Operators should require, in writing, the PSP's MED defense workflow, the SLA for evidence submission, and the operator's role in furnishing evidence inside the 7-day window. Specific operator-side losses are already documented on the lottery rail, with patterns the betting segment shares.

The 80-day filing window cannot be shortened. The operator's only control is the evidence ready inside the 7 days the analyst has. The wallet-ledger architecture and the same-CPF cross-check decide what evidence the operator can produce. The PSP's webhook contract decides what the analyst sees. Operators with both lines locked stay below the MED 2.0 loss curve. Operators with either line ragged absorb settlements they could have defended. Pix is irrevocable on the SPI; the operator's defense is the only thing standing between a deposit on day 0 and a debit on day 60.