> ## Documentation Index
> Fetch the complete documentation index at: https://docs.lerian.studio/llms.txt
> Use this file to discover all available pages before exploring further.
# MED
> Learn how the Pix MED process handles fraud, unauthorized transactions, and operational errors under BACEN deadlines, with pacs.004 refunds through SPI.
MED (Mecanismo Especial de Devolução) is the special refund mechanism of the **Central Bank of Brazil (BACEN)**. It defines how institutions investigate a disputed Pix transaction, communicate with each other, decide the outcome, and execute a refund.
MED is mandatory and follows one standard. It protects the consumer and keeps the process consistent and auditable across every institution.
# When MED applies
***
A Pix transaction enters the MED process when a financial institution needs a **formal, regulated investigation**. Common cases include:
* **Fraud** (phishing, account takeover, social engineering)
* **Unauthorized transactions** (the user did not approve the payment)
* **Operational errors** (duplicate sends, wrong recipient, wrong amount)
* **System or processing failures** that cause financial impact
MED runs **independent** of the standard Pix refund flows. A standard refund is voluntary. MED is mandatory and follows BACEN rules.
# Regulatory MED lifecycle
***
Every MED case runs as an **infraction report** with a fixed set of states. The report opens as `OPEN`, moves to `ACKNOWLEDGED`, and ends as `CLOSED` or `CANCELLED`. Each state carries its own BACEN deadline and response requirement.
### Lifecycle overview
# Integration points
***
MED is a regulatory process, but it works with the core Pix components:
| Component | Role |
| ----------------------- | --------------------------------------------------------------- |
| **DICT** | Provides fraud markers, key metadata, and ownership information |
| **SPI (pacs.004)** | Executes the refund movement between institutions |
| **Midaz Ledger** | Records the balance movements when a refund settles |
| **Pix Switch services** | Coordinate the case lifecycle, deadlines, and notifications |
# Compliance expectations
***
An institution that runs MED must:
* Meet **every regulatory deadline**
* Keep a full **audit trail** with timestamps and event logs
* Send standardized MED messages to the counterpart institution
* Track each case status and its SLA
* Notify the customer consistently
* Use the correct dispute categories and reason codes
# Relationship with refunds and reversals
***
A **refund** and a **reversal** are standard Pix operations. MED provides the regulated mechanism for these cases:
* The refund is tied to fraud or unauthorized activity
* The originating institution disputes the transaction
* The case needs extra evidence and regulated communication
In these cases, the MED decision drives the refund. The institution does not process it as a voluntary action.
# Infraction reports
***
An infraction report is the formal way a Pix participant reports suspected fraud or unauthorized activity on a transaction. It is the entry point of the MED dispute-resolution process.
## When to file an infraction report
A Pix participant files an infraction report when a customer reports fraud or unauthorized activity. The report names the counterparty and starts the investigation. Pix Switch receives the report as the counterparty. It can also cancel a report that it filed as the reporter.
An infraction report carries a **situation type** that classifies the dispute:
| Situation type | Meaning |
| ------------------- | ------------------------------------------------------------------ |
| `SCAM` | The customer was tricked into authorizing the payment |
| `ACCOUNT_TAKEOVER` | A third party took control of the account |
| `COERCION` | The customer paid under coercion |
| `FRAUDULENT_ACCESS` | The payment came from unauthorized channel access |
| `OTHER` | Another situation, described in the report details |
| `UNKNOWN` | The situation is not one of the categories above (BACEN catch-all) |
## Time limits and deadlines
An infraction report follows strict regulatory deadlines:
| Rule | Time limit |
| --------------------- | --------------------------------------------------------------------------------- |
| Transaction age limit | A report applies only to a transaction from the **last 80 days** |
| Analysis period | The counterparty has **7 calendar days** to analyze and close the report |
| Refund request window | After an `AGREED` close, the reporter has **72 hours** to create a refund request |
| Fund release | The blocked funds release when no refund request arrives within 72 hours |
## Infraction report lifecycle
An infraction report moves through these statuses:
| Status | Description |
| -------------- | ----------------------------------------------------------------------------------- |
| `OPEN` | The report is filed and waits for analysis |
| `ACKNOWLEDGED` | The counterparty received and acknowledged the report |
| `CLOSED` | Analysis is complete and the report closes with an `AGREED` or `DISAGREED` result |
| `CANCELLED` | The reporter cancelled the report (from `OPEN`, `ACKNOWLEDGED`, or `CLOSED` status) |
## Closure and automatic fraud markers
When an infraction report closes with an `AGREED` result, the system creates a **fraud marker** for the affected individual automatically. This links the investigation to the anti-fraud system and tracks the flagged individual across the Pix ecosystem.
## Available operations
* **List**: Query infraction reports with filters (status, situation type, linked funds recovery)
* **Retrieve**: Get the full details of one report
* **Acknowledge**: Acknowledge an `OPEN` report as the receiving counterparty
* **Close**: Submit the analysis with an `AGREED` or `DISAGREED` result
* **Cancel**: Cancel a report you filed (from `OPEN`, `ACKNOWLEDGED`, or `CLOSED` status)
# Refund requests
***
A refund request returns funds to the original sender after the participant confirms an infraction. It is the financial execution step of the MED process.
## When to create a refund request
You create a refund request after the participant investigates and closes an infraction report. The rules depend on the reason:
| Reason | Prerequisite |
| ------------------ | --------------------------------------------------------------------------------------------------- |
| `FRAUD` | Needs a closed infraction report with an `AGREED` result. Create it within **72 hours** of closure. |
| `OPERATIONAL_FLAW` | Needs no prior infraction report. Use it for a processing error or operational issue. |
## Time limits
| Rule | Time limit |
| ---------------------- | ------------------------------------------------------------------------------------------------------------------------------- |
| Transaction age | Create a refund request within **80 days** of the original transaction (**30 days** if the original was itself a refund) |
| Post-infraction window | For the `FRAUD` reason, create it within **72 hours** after the infraction closes |
| Monitoring period | For a partial refund or an insufficient-balance rejection, monitor the account and process more partial refunds as funds arrive |
## Analysis outcomes
When the counterparty analyzes a refund request, one of three outcomes applies:
| Result | Description |
| -------------------- | --------------------------------------------------------------- |
| `TOTALLY_ACCEPTED` | The full refund is approved and executed |
| `PARTIALLY_ACCEPTED` | A partial refund is approved, for example on insufficient funds |
| `REJECTED` | The refund is denied, with a rejection reason |
A rejection carries one of these reasons: `NO_BALANCE` (insufficient funds), `ACCOUNT_CLOSURE` (a closed account), `INVALID_REQUEST` (a request that does not meet the rules), `PARTICIPANT_EXCLUSION` (the participant is excluded from settlement), or `OTHER`.
## Available operations
* **Create**: Open a new refund request for a transaction
* **List**: Query refund requests with filters (status, refund reason, transaction, infraction report, participant)
* **Retrieve**: Get the full details of one request
* **Close**: Submit the closure decision with the analysis result
* **Cancel**: Cancel a refund request before processing (only from `OPEN` status)
# Fraud markers
***
A fraud marker flags an individual (by CPF/CNPJ) and a Pix key as linked to fraudulent activity. It is a central part of the Pix anti-fraud ecosystem, managed through BACEN's DICT.
## How fraud markers are created
A fraud marker starts in one of two ways:
1. **Directly**: A participant registers a fraud marker for a tax ID and a Pix key through the API
2. **Automatically**: When an infraction report closes with an `AGREED` result, the system creates a fraud marker for the affected individual
## Fraud classification types
When an infraction report closes with `AGREED`, the reporter records a fraud classification:
| Type | Description |
| ------------------- | ------------------------------------------------- |
| `APPLICATION_FRAUD` | Identity theft or a false application |
| `MULE_ACCOUNT` | An account used to receive and move illicit funds |
| `SCAMMER_ACCOUNT` | An account used to scam victims |
| `OTHER` | A fraud type outside the specific categories |
## Fraud marker lifecycle
| Status | Description |
| ---------- | --------------------------------------------------------------------------- |
| `ACTIVE` | The marker is active and visible in anti-fraud queries across the ecosystem |
| `INACTIVE` | The marker is cancelled and no longer active |
Only the participant that created a fraud marker can cancel it. A cancelled marker stays inactive. Create a new marker if you need one again.
## Available operations
* **Create**: Register a new fraud marker for a tax ID and a Pix key
* **List**: Query fraud markers
* **Retrieve**: Get the full details of one marker
* **Cancel**: Cancel a marker (only from `ACTIVE` status)
# Statistics and risk assessment
***
The MED statistics capabilities return aggregated anti-fraud and transaction data for risk assessment. This data helps an institution evaluate the risk of a person or a Pix key before it processes a transaction.
## What statistics are available
Statistics come at two levels:
### Person statistics (by CPF/CNPJ)
This level aggregates data for one individual or entity. The provider returns:
* **Settlement history**: The count of settled transactions over each period
* **Fraud markers**: Counts by fraud type
* **Total fraud amounts**: The monetary impact of fraud-related transactions
* **Infraction reports**: Open and rejected report counts
* **Registered accounts**: The count of accounts with Pix keys linked to this person
### Key statistics (by Pix key)
This level covers one Pix key, plus the current owner's statistics:
* **Key-level data**: Settlement history, fraud markers, infraction reports, and account registrations for the key
* **Owner-level data**: The full person statistics for the key's current owner
## Time periods
The provider aggregates statistics over three time windows:
| Period | Code | Description |
| --------- | ----- | --------------------------------------------------------- |
| 90 days | `d90` | Recent activity, most relevant for active fraud detection |
| 12 months | `m12` | Medium-term view of behavior patterns |
| 60 months | `m60` | Long-term historical context |
## Use cases
* **Pre-transaction risk scoring**: Query the destination key statistics before you approve a cash-out
* **Onboarding verification**: Check person statistics during account opening or key registration
* **Monitoring dashboards**: Track fraud-marker trends across your portfolio
* **Regulatory compliance**: Show due diligence in fraud prevention to auditors and regulators
**Regulatory reference**
This page gives a practical overview of Pix. For deeper technical, legal, and regulatory detail, always read the [official documentation](https://www.bcb.gov.br/estabilidadefinanceira/pix-normas) from the **Central Bank of Brazil (BACEN)**. It covers rule changes, deadlines, and official requirements.
BACEN's materials are the authoritative source for Pix rules. They hold the most complete and current specifications.