> ## 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. # Transacciones > Las transacciones Pix son el flujo operacional central del sistema de pagos instantáneos de Brasil. Representan el movimiento en tiempo real de fondos entre cuentas a través de todos los participantes de Pix, siguiendo los estándares técnicos y regulatorios establecidos por el Banco Central de Brasil (BACEN). Las transacciones Pix están diseñadas en torno a velocidad, trazabilidad e interoperabilidad — asegurando un comportamiento consistente independientemente de la institución o canal front-end. # Características clave *** Las transacciones Pix comparten una base común en todas las instituciones: ### Liquidación instantánea Los fondos típicamente se liquidan en **10 segundos**, con SPI garantizando la finalización o el timeout manejado de forma transparente. ### Disponibilidad 24/7 Pix opera continuamente — incluyendo fines de semana, feriados y fuera del horario comercial. ### Irrevocabilidad Una vez que un Pix está completado y acreditado, no puede ser revertido excepto a través de flujos regulados (Reembolsos, Devoluciones, MED). ### ID End-to-End (E2E) Cada transacción Pix recibe un identificador E2E único para auditabilidad, conciliación y manejo de disputas. ### Interoperabilidad Cualquier participante de Pix puede enviar o recibir Pix de cualquier otro, independientemente de la institución, plataforma o canal. ### Límites configurables Las instituciones deben aplicar límites regulatorios e internos para seguridad y control de fraude. # Cómo funciona una transacción Pix (Flujo End-to-End) *** Flujo de extremo a extremo de una transacción Pix entre la institución pagadora y la receptora A continuación se muestra una vista simplificada de una transacción Pix entre instituciones: 1. **Iniciación** El usuario inicia una transferencia Pix usando uno de los métodos de direccionamiento disponibles: * Clave Pix * Código QR (estático o dinámico) * Datos bancarios manuales * Código EMV de copiar y pegar Para aprender más sobre los códigos QR de Pix, por favor visite la [documentación de Códigos QR](/es/rails/pix/main-domains-qrcodes). 1. **Autenticación y autorización** La institución remitente debe autenticar al usuario con mecanismos robustos (ej., biometría, 2FA, confianza del dispositivo). El consentimiento del usuario es obligatorio. 2. **Validación y verificaciones de riesgo** Antes de enviar cualquier cosa al SPI, la institución debe validar: * Condición de la cuenta (activa, no bloqueada, KYC verificado) * Disponibilidad de saldo * Límites (por transacción, diarios, nocturnos, mensuales) * Validez de la clave Pix (si aplica) * Evaluaciones de riesgo (indicadores antifraude, verificaciones de velocidad) 3. **Intento de liquidación (SPI)** La institución envía la transferencia al **SPI (Sistema de Pagos Instantáneos de BACEN)**, que: * Valida el mensaje * Lo enruta a la institución receptora * Liquida la transacción entre instituciones 4. **Crédito al receptor** La institución receptora debe acreditar la cuenta **inmediatamente**, incluso si: * Ocurre fuera del horario comercial * Los sistemas están bajo carga * El monto es alto (excepto para casos marcados por antifraude) 5. **Notificaciones y generación de E2E** * Ambas instituciones reciben el estado actualizado de la transacción * La transacción recibe un **ID E2E** único * Webhooks o notificaciones internas actualizan sistemas y usuarios # Tipos de transacciones Pix *** Las transacciones Pix se clasifican en algunas categorías estandarizadas gobernadas por BACEN. ## 1. Cash-Out (Enviar Pix) El pagador envía fondos a otra cuenta usando una clave Pix, código QR o datos bancarios. **Flujo (resumen):** 1. El usuario inicia la transferencia 2. La institución verifica saldo + límites + clave 3. La transacción se envía al SPI 4. El receptor acredita instantáneamente 5. Ambas partes reciben actualizaciones + ID E2E Escenarios comunes: * Transferencias P2P * Pagos a comerciantes * División de cuentas * Pagos divididos de marketplace (cuando se combina con Pix Cobrança) ## 2. Cash-In (Recibir Pix) El cliente recibe una transferencia Pix de cualquier otra institución. **Flujo (resumen):** 1. La institución receptora es notificada vía SPI 2. La cuenta debe ser acreditada inmediatamente 3. Las notificaciones se envían para conciliación 4. La transacción se registra con ID E2E Escenarios comunes: * Salarios o desembolsos corporativos * Liquidaciones de comerciantes * Pagos recurrentes de clientes ## 3. Reembolso (Devolución) Flujo regulado que permite a las instituciones devolver fondos al remitente original. Los reembolsos pueden ser activados por: * Solicitud del cliente * Reembolsos de comerciantes * Pagos duplicados * Errores operacionales * Casos MED relacionados con fraude Los reembolsos deben: * Usar mensajería estándar de BACEN * Estar vinculados a la transacción original * Seguir reglas de valor y elegibilidad ## 4. Reversión (Chargeback / pacs.004) Usado en casos regulados especiales — a menudo vinculados a MED o correcciones operacionales. Las reversiones siguen reglas estrictas de BACEN y **no** son lo mismo que reembolsos de comerciantes. # Cash-out: patrón de transferencia en dos fases *** Cuando un cash-out de Pix se procesa a través de la plataforma Lerian, la transferencia sigue un **patrón de dos fases** que separa la validación del movimiento de fondos. Este diseño proporciona seguridad, cumplimiento y una mejor experiencia tanto para instituciones como para usuarios finales. ## Por qué dos fases Ejecutar una transferencia Pix implica múltiples validaciones: búsqueda de clave, verificación de cuenta, verificaciones de saldo, aplicación de límites y evaluación antifraude. Realizar todo esto en un solo paso crea riesgo — si algo falla después de una ejecución parcial, la reversión se vuelve compleja. El patrón de dos fases resuelve esto dividiendo el proceso: 1. **Fase 1 — Iniciar**: Validar todo sin mover fondos 2. **Fase 2 — Procesar**: Ejecutar la transferencia de fondos usando los datos validados Esta separación proporciona varias ventajas: * **Validación antes del compromiso**: Todas las verificaciones (saldo, límites, validez de clave, antifraude) ocurren antes de que se mueva dinero * **Confirmación del usuario**: La aplicación iniciadora puede mostrar los detalles validados del destino al usuario antes de que confirme la transferencia * **Soporte de idempotencia**: Cada fase puede reintentarse independientemente sin riesgo de transferencias duplicadas * **Cumplimiento**: Las validaciones regulatorias se completan y registran antes de que comience el movimiento de fondos ## Cómo funciona ### Fase 1: Iniciar La fase de iniciación crea un registro de transferencia recuperando y validando la información del destino. No se mueven fondos en esta etapa. La plataforma soporta tres tipos de iniciación: | Tipo | Descripción | Entrada | | --------- | ------------------------------------------------------------------- | ---------------------------------------------------- | | `MANUAL` | Detalles completos de la cuenta destino proporcionados directamente | Banco, sucursal, número de cuenta, documento, nombre | | `KEY` | Destino resuelto mediante búsqueda de clave Pix (DICT) | Valor de la clave Pix (CPF, email, teléfono, EVP) | | `QR_CODE` | Destino extraído de un payload de código QR | Cadena BR Code (EMV) | Para iniciaciones `KEY` y `QR_CODE`, la plataforma consulta automáticamente DICT para resolver la cuenta destino, proporcionando a la aplicación iniciadora detalles completos — nombre del titular de la cuenta, institución y fecha de propiedad de la clave — que pueden mostrarse para confirmación del usuario. La iniciación devuelve un identificador único y una marca de tiempo de expiración. La aplicación usa este identificador en la siguiente fase. ### Fase 2: Procesar La fase de procesamiento toma la iniciación validada y ejecuta el movimiento real de fondos: * Verifica que la iniciación aún es válida (no expirada, no procesada previamente) * Debita la cuenta de origen en el ledger * Envía el pago a la infraestructura de liquidación Pix (SPI) * Registra la transferencia con trazabilidad completa (ID end-to-end, marcas de tiempo, estado) Una vez que el procesamiento comienza, la transferencia sigue el flujo estándar de liquidación Pix y no puede cancelarse — solo reembolsarse a través del proceso regulado de reembolso. ## Resumen del ciclo de vida | Paso | Qué sucede | ¿Fondos movidos? | | -------------------- | ------------------------------------------------------------------- | :--------------: | | **Iniciar** | Validar destino, verificar clave/QR, resolver detalles de cuenta | No | | **Usuario confirma** | La aplicación muestra detalles, el usuario aprueba la transferencia | No | | **Procesar** | Debitar cuenta de origen, enviar a SPI, acreditar destino | Sí | | **Completar** | ID end-to-end asignado, ambas partes notificadas | — | # Transacciones Pix intra-ledger *** Cuando ambas cuentas pertenecen a la misma institución: * La transferencia **no** pasa por SPI * La institución la procesa internamente * El ID E2E aún puede asignarse para trazabilidad * Todas las validaciones estándar aplican (límites, fraude, saldo) Este modo reduce la latencia y dependencias externas mientras preserva la semántica de Pix. # Capas de validación (Regulatoria + Operacional) *** Cada transacción Pix pasa por múltiples validaciones antes de ser enviada al SPI: ### 1. Verificaciones de cuenta * Cuenta activa * No bloqueada * KYC completo ### 2. Disponibilidad de fondos * Saldo suficiente * Retenciones temporales liberadas ### 3. Validación de clave Pix Si el usuario paga vía clave, los detalles del destinatario deben obtenerse de DICT y confirmarse. ### 4. Límites regulatorios * Por transacción * Límite diario * Límite nocturno (obligatorio) ### 5. Verificaciones de riesgo y fraude Las instituciones pueden aplicar: * Verificaciones de velocidad * Huella digital del dispositivo * Análisis de comportamiento * Marcadores de fraude conocido ### 6. Idempotencia Cada transferencia Pix debe tener un ID de transacción único. Esto evita transferencias duplicadas durante reintentos. # Controles operacionales y seguridad *** ### Requisitos de autenticación La autenticación robusta del cliente es obligatoria para todas las operaciones de envío Pix. ### Notificaciones y Webhooks Después de acreditar, las instituciones deben notificar a sistemas y usuarios. Los webhooks permiten conciliación en tiempo real. ### Manejo de errores Las categorías de error comunes incluyen: * Timeout * Clave inválida * Fondos insuficientes * Límite diario/nocturno excedido * Transacción sospechosa bloqueada ### Auditabilidad Pix requiere trazabilidad completa: * Logs * Marcas de tiempo * ID E2E * Metadatos de cuenta # Límites de transacción (Reglas BACEN) *** Los límites de transacción Pix existen para reducir el riesgo de fraude, proteger a los usuarios finales y mantener la seguridad operacional en todo el ecosistema de pagos instantáneos. BACEN define **estándares mínimos de seguridad**, y las instituciones pueden agregar restricciones adicionales dependiendo de su apetito de riesgo. Los límites de Pix se dividen en **límites regulatorios obligatorios** y **límites definidos por la institución**. ## 1. Límites regulatorios obligatorios (BACEN) ### Límite nocturno (Tope por transacción) Las instituciones **deben** aplicar un límite máximo más bajo entre **20:00 y 06:00**. Requisitos regulatorios: * Máximo por defecto: **R\$ 1.000** * Las instituciones pueden establecer un valor por defecto más bajo (ej., R$ 500 o R$ 200) * Los clientes pueden **reducir** este límite instantáneamente * Los clientes pueden **aumentar** este límite **solo después de un mínimo de 24 horas de espera** * Los clientes pueden **ajustar la ventana nocturna** (ej., extender a 18h–08h) Esta regla aplica a: * Transferencia Pix (cash-out) * Pago con código QR Pix * Pix Saque/Troco * Pagos Pix Cobrança iniciados de noche Su propósito es prevenir fraudes durante horas de mayor riesgo. ### Provisión para límites controlados por el cliente Las instituciones deben ofrecer a los clientes la capacidad de **configurar sus propios límites**, por: * Transacción * Día * Máximo nocturno * Otras formas de segmentación basada en riesgo Estos cambios deben respetar las reglas de tiempo de BACEN: * **Reducciones** → deben tener efecto **inmediatamente** * **Aumentos** → solo pueden tener efecto **después de un mínimo de 24 horas** (retraso de seguridad) ### Obligación de analizar solicitudes de aumento de límite Cada institución debe: * Aceptar solicitudes de clientes para aumentar límites * Evaluarlas a través de criterios de riesgo * Otorgar o denegar basándose en política de fraude * Aplicar aumentos solo **después del período de espera regulatorio (24h+)** ### Límites de Saque/Troco (Retiro de efectivo en comercios) Pix Saque y Pix Troco tienen sus propios topes: * Por defecto: **R\$ 500** por transacción * Las instituciones pueden ofrecer voluntariamente hasta **R\$ 3.000** por transacción * Los clientes pueden reducir este límite instantáneamente * Los aumentos siguen la misma regla de 24h Estos límites *no* afectan las transferencias normales — son específicos para modalidades de retiro de efectivo. ### Obligaciones de crédito (independientes de límites) Incluso si se exceden los límites, una vez que un Pix es **acreditado** al receptor: * La transacción se vuelve **irrevocable** * Solo los flujos MED o de reembolso pueden revertirla * Las instituciones no pueden "deshacer" un Pix completado por iniciativa propia ## 2. Límites definidos por la institución (Configurables) Más allá de las reglas obligatorias, las instituciones pueden agregar sus propios controles, como: ### Límite por transacción Monto máximo permitido para una sola operación Pix. ### Límite diario Tope en el monto total de Pix por usuario por día calendario. ### Límite mensual (opcional) Usado principalmente por cuentas corporativas o modelos de riesgo fintech. ### Segmentación basada en riesgo Las instituciones pueden ofrecer: * Límites más estrictos para nuevos clientes (ej.: primeros 7 días) * Diferentes límites para usuarios de alto riesgo o cuentas marcadas * Límites dinámicos ajustados por comportamiento del cliente Estos controles internos nunca deben entrar en conflicto con los requisitos de BACEN — solo complementarlos. ## 3. Reglas operacionales requeridas por BACEN ### Reducción inmediata de límite Los clientes pueden reducir sus límites instantáneamente. ### Aumento de límite retrasado Todos los aumentos deben respetar: * **24 horas mínimo** antes de hacerse efectivos * Período de espera adicional opcional (elección de la institución) ### Horas de riesgo pico Los límites nocturnos aplican específicamente a **flujos de cash-out**, ya que representan el principal vector de pérdidas por fraude. ### Aplicación en tiempo real Las instituciones deben verificar límites *antes* de enviar una transacción al SPI. Un Pix que viola límites debe ser rechazado **localmente**, no después de llegar al SPI. ## 4. Comportamiento de límites en el ciclo de vida de la transacción ### Durante una iniciación Pix La institución remitente debe verificar: * Saldo disponible * Límite de transacción * Límite diario * Límite nocturno * Límite de Saque/Troco (si aplica) * Límites de fraude/velocidad * Límites configurados por el cliente Si alguna regla es violada → la transacción debe ser rechazada con un código apropiado. ### Durante reintentos Los límites deben validarse nuevamente. La idempotencia previene transferencias duplicadas pero **no** evita las verificaciones de límites. ### Durante flujos de comerciantes Los códigos QR dinámicos también deben respetar: * Límites del cliente * Reglas de hora del día * Topes de Saque/Troco Incluso si el comerciante establece un monto, la institución del pagador decide si aprueba. ## 5. Comunicación recomendada al cliente BACEN requiere que las instituciones: * Expliquen los límites claramente * Ofrezcan autoservicio al cliente para ajustar límites * Muestren aumentos pendientes y fechas de activación * Notifiquen a los clientes en caso de comportamiento sospechoso ## 6. Tabla resumen | Tipo de Límite | ¿Obligatorio? | Por Defecto (BACEN) | Controles del Cliente | Reglas de Activación | | ------------------ | ------------- | ------------------------ | -------------------------- | ------------------------------------ | | Por transacción | Opcional | Definido por institución | Aumentar/reducir | Reducir = inmediato / Aumentar = 24h | | Diario | Opcional | Definido por institución | Aumentar/reducir | Reducir = inmediato / Aumentar = 24h | | Nocturno (20h–06h) | **Sí** | **Máx R\$ 1.000** | Personalizable por cliente | Aumentar = retraso 24h | | Saque/Troco | **Sí** | R\$ 500 por defecto | Configurable por cliente | Aumentar = retraso 24h | | Mensual | Opcional | Definido por institución | Aumentar/reducir | Definido por institución | **Referencia regulatoria** Esta página proporciona una visión general práctica de cómo funciona Pix. Para detalles técnicos, legales y regulatorios más profundos — y para mantenerse actualizado con cambios de reglas, plazos y requisitos oficiales — siempre consulte la [documentación oficial](https://www.bcb.gov.br/estabilidadefinanceira/pix-normas) publicada por el **Banco Central de Brasil (BACEN)**. Los materiales de BACEN son la fuente autorizada para las regulaciones de Pix y contienen las especificaciones más completas y actualizadas.