> ## Documentation Index
> Fetch the complete documentation index at: https://docs.trio.com.br/llms.txt
> Use this file to discover all available pages before exploring further.

# Simulate deposit failures

> Use bank account parameters to reproduce rejected and refunded deposits in the sandbox.

Besides validating input on your side, you should see how Trio behaves when a deposit is refused: a payer with an invalid CPF or CNPJ, a legal entity paying a code meant for individuals, a repeated payment of the same QR code. This guide turns on the bank account rules that reject or refund such deposits and pays a QR code against them.

## Before you start

The simulation uses the two-account setup from [Simulate a successful deposit](https://docs.trio.com.br/v2/guides/receivables/simulating-deposit-success.md): one bank account generates the QR code and the other pays it. Read that guide first if you have not set the accounts up.

## Account rules

Each bank account carries a set of security and compliance rules that apply business logic and fraud prevention to incoming and outgoing transactions. In V2 they are exposed as the `parameters` object of the bank account. Read them with [`GET /v2/bank_accounts/{id}`](https://docs.trio.com.br/v2/api-reference/banking-api/bank-accounts/get-bank-account) and toggle them with [`PUT /v2/bank_accounts/{id}`](https://docs.trio.com.br/v2/api-reference/banking-api/bank-accounts/update-bank-account), which takes the boolean flags listed in the table:

```json theme={null}
{
  "in_block_for_legal_entity": true,
  "in_block_for_pix_qrcode_different_amount_payment": true
}
```

| Rule ID | Rule | V2 parameter | Description |
| - | - | - | - |
| **1** | Block payins from unidentified individuals | `in_block_for_unidentified_deposit` | Rejects payments where the sender's identity could not be verified. |
| **2** | Block duplicated QR code payins | `in_block_for_pix_qrcode_duplicated_payment` | Prevents repeated payments using the same QR code. |
| **3** | Block payins with a different amount from the dynamic QR code amount | `in_block_for_pix_qrcode_different_amount_payment` | Ensures that the received amount matches the amount defined in the dynamic QR code. |
| **4** | Block payins from legal entities | `in_block_for_legal_entity` | Prevents receiving funds from companies (CNPJ), allowing only individuals (CPF). |
| **5** | Block payins from tax numbers different from the dynamic QR code tax number | `in_block_for_pix_qrcode_different_tax_number` | Ensures that the payer's tax number matches the one associated with the QR code. |
| **6** | Block payins from unauthorized participants | `in_block_for_unauthorized_participant` | Blocks payments from blacklisted participants. |
| **7** | Block payins from counterparty bank accounts different from the QR code | `in_block_for_pix_qrcode_different_counterparty_bank_account` | Verifies that the sender's bank account matches the account expected for the QR code payment. |
| **8** | Automatic refund for deposits incoming from minors | `automatic_refund_for_person_underage` | Automatically refunds deposits made by individuals under 18 years old. |
| **9** | Automatic refund for deposits incoming from deceased individuals | `automatic_refund_for_person_dead` | Automatically refunds payments made by individuals marked as deceased in official records. |
| **10** | Automatic refund for deposits incoming from individuals with invalid tax numbers | `automatic_refund_for_person_invalid_tax_number` | Automatically refunds payments from individuals with invalid CPF or CNPJ values. |
| **11** | Block payouts to legal entities (CNPJ) | `out_block_for_legal_entity` | Prevents outgoing payouts to companies, allowing payouts only to individuals. |

The V2 `parameters` object also carries an `out_blocked` flag, which has no counterpart in this table. Understanding these rules matters both for your integration and for testing the different transaction scenarios.

## Simulate a failure

**1. Open the rules of the receiving account**

In the [Trio App](https://app.sandbox.trio.com.br), list your bank accounts and click **Actions** on the account that generates the QR code. The rules are at the bottom of the account details page.

![](https://mintcdn.com/trio-372e8dab/xz71XpWMTdfzGqWm/images/image-\(37\).png?fit=max\&auto=format\&n=xz71XpWMTdfzGqWm\&q=85\&s=c19e18d8bf1abeac1566dbf0bb270393)

Through the API, read the same rules with `GET /v2/bank_accounts/{id}`.

**2. Enable the rule you want to test**

Turn on the rule in the Trio App, or send its parameter as `true` with `PUT /v2/bank_accounts/{id}`. The JSON above enables rules 3 and 4.

**3. Create a QR code on that account**

Generate a dynamic QR code with the receiving account's `id` in `bank_account_id`, as in [Cash in](https://docs.trio.com.br/v2/guides/receivables/cash-in.md).

**4. Pay the QR code from the other account**

Paste the BR code in the Trio App as described in [Simulate a successful deposit](https://docs.trio.com.br/v2/guides/receivables/simulating-deposit-success.md). The banking application shows the error below instead of settling the payment, which is what end users see in production:

`Invalid Pix Key/Copy & Paste`

![](https://mintcdn.com/trio-372e8dab/5cvf6IfT-hgKrVWt/images/image-\(36\).png?fit=max\&auto=format\&n=5cvf6IfT-hgKrVWt\&q=85\&s=0da1c142a791e566c0f5419fbee9e7d2)

## What you see on the Trio side

> [!NOTE]
>
> Most payment failures happen during the initial validation, and the error goes straight back to the payer's banking application. In these cases no transaction record is created on the Trio side and your integration has nothing to handle. This early rejection applies to rules **1**, **2**, **5**, **6**, **8**, **9** and **10**.

When a deposit is recorded on the Trio side, follow it through its `status` and `stages`, listed by [`GET /v2/documents/in`](https://docs.trio.com.br/v2/api-reference/banking-api/documents/receivables/list-receivables), and through [webhook events](https://docs.trio.com.br/v2/webhooks/events/overview.md). The [Document lifecycle](https://docs.trio.com.br/v2/guides/pix/document-lifecycle.md) guide describes the statuses.

## Next steps

* [Simulate a successful deposit](https://docs.trio.com.br/v2/guides/receivables/simulating-deposit-success.md): the two-account setup this guide relies on.
* [Document lifecycle](https://docs.trio.com.br/v2/guides/pix/document-lifecycle.md): statuses and stages of an in document.
* [List receivable refunds](https://docs.trio.com.br/v2/api-reference/banking-api/documents/receivables-refunds/list-receivable-refunds.md): the API reference for refunded deposits.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.