Este no es solo un proyecto de tecnología
Existe una percepción común en las primeras etapas de evaluación de Pix Directo: 'es una integración de API'. Técnicamente, hay verdad en ello — pero operacionalmente, es una simplificación que suele costar cara.
Convertirse en participante directo de Pix es una transformación organizacional. Involucra ingeniería, cumplimiento, legal, riesgo, operaciones y producto — todos simultáneamente, con interdependencias que no se hacen evidentes hasta que alguien se estanca en una fase porque esperaba que otra estuviera lista.
Esta guía fue escrita para equipos que están más allá de la fase de '¿valdrá la pena?' y necesitan entender qué está involucrado concretamente. Cubrimos los requisitos del Banco Central, las integraciones técnicas obligatorias, los equipos y responsabilidades, las etapas del proyecto con un cronograma realista — y, principalmente, los errores que las fintechs cometen con más frecuencia y que retrasan o viabilizan el proceso.
📌 Contexto: Si aún estás en la fase de decidir entre Pix Directo y Pix Indirecto, recomendamos comenzar por el artículo Pix Direto vs. Pix Indireto: qual modelo faz mais sentido para sua fintech? — que incluye la matriz de decisión por perfil de empresa y el análisis de costo comparativo.
Requisitos del Banco Central: lo que es innegociable
El Banco Central define con precisión las condiciones para que una institución sea aceptada como participante directo de Pix. No hay margen de flexibilidad en estos requisitos; son la línea divisoria entre ser o no apto para operar.
La Resolución BCB n.º 429/2024 es el documento normativo central, pero el marco regulatorio completo también incluye el Reglamento de Pix, el Manual de Estándares para la Iniciación de Pix (MP Pix) y circulares complementarias. El proceso de adecuación debe contemplar todos estos instrumentos, no solo la resolución más reciente.
Requisito | Descripción | Criticidad |
|---|---|---|
Autorización del BC | Obligatoria: la institución debe estar autorizada para funcionar por el Banco Central (IF o IP) | Alta |
Tipo de institución | IF (banco, cooperativa) o IP (emisor de dinero electrónico, adquirente, ITP) autorizado | Alta |
Capital mínimo | Variable según el tipo de institución y segmento regulatorio — consultar Res. BCB 429/2024 | Alta |
Disponibilidad operativa | SLA mínimo del 99,5%: operación ininterrumpida 24/7/365 sin ventanas no planificadas | Alta |
Sistema antifraude | Solución propia integrada con el mecanismo FRAUD del Banco Central | Alta |
Certificado digital ICP-Brasil | Obligatorio para la autenticación en los mensajes al SPI y DICT | Alta |
Conexión a la RSFN | Red del Sistema Financiero Nacional: canal de comunicación seguro con el BC | Alta |
Gestión de continuidad | Plan formal de contingencia y recuperación ante desastres (BCP/DRP) | Alta |
Protección de datos (LGPD) | Políticas y controles de protección de datos de los usuarios finales | Media |
Equipo de compliance | Estructura interna de riesgo, legal y cumplimiento dedicada a la operación de Pix | Media |
⚠️ Atención: La autorización del BC no es un prerrequisito que pueda resolverse al final del proyecto. El proceso de solicitud y análisis puede tardar de 2 a 6 meses. Comenzar por el desarrollo técnico y dejar el proceso regulatorio para después es el error más costoso que una fintech puede cometer en este camino.
Integraciones técnicas obligatorias
La infraestructura técnica de Pix Direto está compuesta por seis sistemas interdependientes. Comprender el papel de cada uno —y cómo se conectan— es el prerrequisito para cualquier estimación realista de alcance y plazo de desarrollo.
Sistema | Nombre completo | Función | Criticidad |
|---|---|---|---|
SPI | Sistema de Pagamentos Instantâneos | Liquidación de las transacciones en tiempo real en la cuenta PI | Muy alta — núcleo de la operación |
DICT | Diretório de Identificadores de Contas Transacionais | Registro, consulta y portabilidad de claves Pix | Muy alta — necesario para toda transacción |
RSFN | Rede do Sistema Financeiro Nacional | Canal de comunicación seguro con la infraestructura del BC | Alta — prerrequisito de conectividad |
FRAUD | Mecanismo de Prevenção à Fraude do Pix | Intercambio de datos de fraude entre participantes | Alta — requisito regulatorio |
ISO 20022 | Estándar internacional de mensajería financiera | Formato de los mensajes intercambiados con el SPI y DICT | Alta — protocolo obligatorio |
ICP-Brasil | Infraestrutura de Chaves Públicas Brasileira | Autenticación y firma digital en los mensajes al BC | Alta — seguridad de los mensajes |
SPI: el corazón de la liquidación
El Sistema de Pagamentos Instantâneos es donde las transacciones se liquidan de forma definitiva, en tiempo real, en la cuenta PI de la institución. La integración al SPI exige la implementación completa del protocolo ISO 20022 —que no es una API REST convencional. Es un protocolo de mensajería financiera con estructura XML, reglas de validación estrictas y autenticación por certificado digital. Los equipos sin experiencia previa en mensajería financiera suelen subestimar esta complejidad.
DICT: el directorio de claves
El Diretório de Identificadores de Contas Transacionais es la infraestructura que asocia claves Pix (CPF, CNPJ, correo electrónico, teléfono móvil, clave aleatoria) a las cuentas de los usuarios. La integración al DICT permite que la institución registre, consulte y gestione las claves de sus clientes. Es a través del DICT que el sistema identifica a qué cuenta apunta una clave antes de liquidar la transacción en el SPI.
RSFN: el canal seguro
La Rede do Sistema Financeiro Nacional es el canal de comunicación dedicado y seguro por el cual transitan los mensajes entre la institución y la infraestructura del Banco Central. A diferencia de una conexión de internet pública, la RSFN exige la contratación de un proveedor homologado y una configuración específica de red. Es un prerrequisito de conectividad —sin él, no hay comunicación con SPI o DICT.
FRAUD: el mecanismo de antifraude compartido
El mecanismo FRAUD de Pix permite que los participantes compartan información sobre transacciones sospechosas y cuentas fraudulentas en tiempo casi real. La integración a FRAUD es obligatoria y exige que la institución implemente su propia capa de detección de fraude —que alimenta y consulta este sistema centralizado. No basta con integrar: es necesario tener una política de antifraude operativa antes del go-live.
🔗 Profundización técnica: Para entender en detalle cómo funcionan arquitectónicamente el SPI, DICT y la Cuenta PI —incluyendo el flujo completo de una transacción Pix de principio a fin— lea el artículo SPI, DICT y Conta PI: la infraestructura detrás del Pix Direto explicada.
Seguridad y disponibilidad: qué significa el 99,5 % en la práctica
El Banco Central exige una disponibilidad mínima del 99,5% para los participantes directos. Parece una cifra abstracta hasta que se calcula lo que implica: un máximo de 43,8 horas de inactividad al año, y eso incluye los mantenimientos planificados, que deben comunicarse previamente al BC.
Alcanzar y mantener este SLA no es una decisión de código; es una decisión de arquitectura y cultura operativa. Algunas implicaciones prácticas:
Redundancia activa: no hay tolerancia para puntos únicos de fallo (single points of failure). La arquitectura necesita redundancia en múltiples capas: aplicación, base de datos, red, zona de disponibilidad.
Failover automático: la recuperación ante fallos no puede depender de la intervención manual. Cada componente crítico necesita un mecanismo de failover automático con tiempos de detección y conmutación en segundos.
Monitoreo en tiempo real: las alertas de degradación del rendimiento deben llegar antes de que el SLA se vea afectado, no después. Esto exige la definición de SLIs (Service Level Indicators) precisos y umbrales de alerta bien calibrados.
On-call estructurado: alguien con capacidad para actuar debe estar disponible a cualquier hora, cualquier día. Esto no es una guardia informal; es una estructura de escalamiento con runbooks, herramientas y responsabilidades claras.
Ventanas de mantenimiento comunicadas: cualquier mantenimiento que afecte a la disponibilidad debe comunicarse al BC dentro de los plazos regulatorios. El mantenimiento no comunicado cuenta como inactividad no planificada.
💡 Referencia: El coste de montar y mantener esta estructura operativa —incluyendo infraestructura cloud redundante, herramientas de observabilidad y el modelo on-call— se detalla en el artículo ¿Cuánto cuesta operar con Pix Directo?, que incluye rangos de OPEX mensual según el tamaño de la institución.
Equipos involucrados: quién hace qué
Uno de los mayores riesgos de los proyectos de participación directa es que sean tratados como un proyecto exclusivo de ingeniería. En la práctica, atraviesa al menos seis áreas de la organización —y la falta de alineación entre ellas es una de las causas más comunes de retrasos.—
La siguiente tabla mapea los equipos, sus responsabilidades específicas en el proyecto y el papel central de cada uno:
Equipo | Responsabilidades en el proyecto | Papel clave |
|---|---|---|
Ingeniería / Plataforma | Integración técnica al SPI, DICT, RSFN y FRAUD. Desarrollo de la capa de mensajería ISO 20022. Infraestructura cloud y observabilidad. | Lidera la ejecución técnica del proyecto |
Compliance y Regulatorio | Análisis de la Resolución BCB 429/2024, adecuación a las exigencias del BC, reporte regulatorio, gestión de incidentes con el BC. | Responsable de la relación con el Banco Central |
Riesgo y Antifraude | Definición de políticas de fraude, implementación del sistema de prevención, integración al mecanismo FRAUD, monitoreo continuo. | Define las reglas que protegen la operación |
Legal | Análisis de contratos con proveedores, adaptación a la LGPD, revisión de términos y condiciones con participantes indirectos. | Soporte transversal al proyecto |
Operaciones / SRE | Definición de guardias (on-call), manuales de procedimientos (runbooks) de incidentes, gestión de SLA 24/7, monitoreo de disponibilidad. | Garantiza la continuidad operativa tras el go-live |
Producto | Definición de funcionalidades Pix nativas, experiencia del usuario, priorización del roadmap posterior a la infraestructura, gestión de partes interesadas internas. | Garantiza que la infraestructura se convierta en producto |
Seguridad de la Información | Gestión de certificados ICP-Brasil, políticas de acceso, pruebas de penetración (pen tests), auditoría de seguridad. | Garantiza la conformidad de seguridad |
Un punto que merece especial atención: el equipo de producto tiende a ser movilizado demasiado tarde en estos proyectos. La infraestructura de participación directa solo genera valor cuando se convierte en producto —y esto requiere que producto esté involucrado desde el inicio, definiendo qué funcionalidades se lanzarán en el go-live y cuál será el roadmap de las siguientes iteraciones.—
🏗️ Build vs. Buy vs. Socio tecnológico: Para equipos sin experiencia previa en integración al SPI, la opción de contratar a un proveedor especializado puede reducir el plazo de implementación entre un 30 % y un 50 % y disminuir significativamente el riesgo técnico. La decisión de build vs. buy debe tomarse formalmente, con un análisis de TCO, antes de asignar recursos al equipo de ingeniería.
Etapas do projeto e timeline realista
El proceso completo —desde el análisis inicial hasta la puesta en producción (go-live)— dura normalmente entre 12 y 24 meses. Este amplio intervalo refleja variaciones reales del mercado: una institución ya autorizada por el BC, con un equipo técnico con experiencia en mensajería financiera y que opta por un socio tecnológico puede llegar a la puesta en producción en 12 meses. Una institución que necesita solicitar la autorización desde cero, construir todo internamente y sin experiencia previa en el SPI puede tardar 24 meses o más.
Fase | Nombre | Duración típica | Qué ocurre |
|---|---|---|---|
Fase 1 | Análisis regulatorio y evaluación de brechas (gap assessment) | 1–3 meses | Mapeo de requisitos del BC, análisis de conformidad de la institución, decisión de desarrollo propio frente a compra (build vs. buy), selección de proveedores. |
Fase 2 | Solicitud de autorización al BC | 2–6 meses | Presentación de la solicitud formal al Banco Central, documentación técnica y operativa, análisis por parte del BC. Plazo altamente variable. |
Fase 3 | Desarrollo e integración técnica | 4–9 meses | Integración con el SPI, DICT, RSFN y FRAUD. Implementación de la mensajería ISO 20022. Certificados ICP-Brasil. Infraestructura de alta disponibilidad. |
Fase 4 | Homologación en el entorno del BC | 2–4 meses | Pruebas en el entorno de homologación del Banco Central. Validación de todos los flujos transaccionales. Corrección de no conformidades. |
Fase 5 | Certificación y aprobación final | 1–2 meses | Proceso formal de certificación. Aprobación del BC para la operación en producción. Preparación para la puesta en producción (go-live). |
Fase 6 | Puesta en producción y estabilización | 1–3 meses | Lanzamiento controlado (se recomienda un despliegue gradual). Monitorización intensiva. Ajustes operativos. Activación del servicio de guardia 24/7 (on-call). |
Dos fases merecen especial atención en la planificación:
Fase 2 — Autorización del BC: el plazo más impredecible
El análisis del BC no sigue un cronograma fijo y público. El plazo depende de la exhaustividad de la documentación presentada, de la lista de espera de solicitudes en ese momento y de la naturaleza de las posibles consultas del BC. Las solicitudes con documentación incompleta o incoherente pueden provocar el reinicio del proceso. Se recomienda iniciar esta fase en paralelo al desarrollo técnico, nunca después.
Fase 4 — Homologación: donde aparecen los problemas
El entorno de homologación del Banco Central es el lugar donde la integración técnica se encuentra con la realidad. Es habitual que en esta fase se detecten incompatibilidades en la mensajería, errores de certificado, comportamientos inesperados en los flujos de error y latencias superiores a las aceptables. Asignar un margen de tiempo generoso en esta fase —al menos un 50 % por encima de la estimación inicial— es una de las decisiones de planificación más importantes del proyecto.
Los 5 errores más comunes, y cómo evitarlos
Estos errores se identificaron en proyectos reales de participación directa. Ninguno de ellos es inusual y todos se pueden evitar con una planificación adecuada.
Error común | Cómo se manifiesta | Cómo evitarlo |
|---|---|---|
Subestimar el plazo regulatorio | Tratar la autorización del BC (Banco Central) como un trámite rápido. El proceso de análisis del BC puede tardar de 2 a 6 meses, y cualquier documentación incompleta reinicia el ciclo. | Iniciar el proceso regulatorio en paralelo al desarrollo técnico, no después. |
Construir sin observabilidad | Lanzar la integración al SPI sin la instrumentación adecuada de registros (logs), métricas y alertas. El primer incidente de producción revela lo que faltaba. | Definir la estrategia de observabilidad antes de escribir la primera línea de código de integración. |
Subestimar el soporte on-call 24/7 | Asumir que el equipo de ingeniería absorberá el soporte fuera del horario comercial sin una estructura formal. Esto genera agotamiento (burnout) y compromete el SLA. | Diseñar el modelo operativo de soporte on-call como un requisito del proyecto, no como un detalle posterior al go-live. |
Ignorar a los participantes indirectos | Centrar toda la atención en la integración con el BC y descuidar la arquitectura para la incorporación (onboarding) de participantes indirectos, si esa es la estrategia. | Definir desde el principio si habrá participantes indirectos y diseñar la arquitectura para darles soporte. |
Desarrollo total sin evaluar la compra (Build vs Buy) | Decidir desarrollar todo internamente sin comparar con plataformas especializadas, por orgullo técnico o desconocimiento del mercado. | Realizar un RFI de proveedores antes de decidir por el desarrollo total. El coste de oportunidad puede ser significativo. |
Lista de verificación de preparación: antes de iniciar el proyecto
Antes de asignar el presupuesto, formar el equipo y poner en marcha el proyecto formalmente, valide los 10 criterios de abajo. No es necesario que todos estén resueltos al 100%, pero cada 'no' o 'no sé' debe tener un plan de acción antes del kick-off.
Categoría | Criterio de preparación |
|---|---|
Regulatorio | ¿La institución cuenta con autorización del BC o tiene una vía clara para obtenerla? |
Regulatorio | ¿El tipo de institución (IF o IP) es elegible para la participación directa? |
Regulatorio | ¿Dispone de un equipo o asesoría jurídica especializada en regulación del BC? |
Técnico | ¿Existe un equipo con experiencia en mensajería financiera / ISO 20022? |
Técnico | ¿La infraestructura en la nube soporta alta disponibilidad y conmutación por error automática? |
Técnico | ¿Hay una estrategia definida de observabilidad (logs, métricas, alertas)? |
Operacional | ¿Está diseñado el modelo de guardia 24/7 y se han definido los responsables? |
Operacional | ¿Existe un plan formal de continuidad de negocio (BCP/DRP)? |
Estratégico | ¿El volumen actual o proyectado justifica la inversión en el modelo directo? |
Estratégico | ¿Se ha evaluado formalmente la decisión de build vs. buy vs. socio tecnológico? |
Si 7 o más criterios tienen respuesta positiva, el proyecto está en condiciones de avanzar con un riesgo controlado. Si hay menos de 5 abordados, es momento de preparación, no de ejecución.
Conclusión: el proyecto que transforma la institución
Convertirse en participante directo de Pix no es un proyecto de infraestructura. Es un proyecto que cambia la posición estratégica de la institución en el ecosistema financiero —y que, si se ejecuta bien, abre oportunidades que el modelo indirecto simplemente no permite: autonomía total de producto, reducción estructural del coste transaccional y la posibilidad de convertirse en referencia de infraestructura para otros actores.
La complejidad es real. El plazo es largo. La implicación es amplia. Pero para las instituciones en la etapa adecuada —con volumen, estrategia y capacidad de ejecución— es exactamente este tipo de proyecto el que define quién liderará el próximo ciclo del mercado de pagos instantáneos en Brasil.
El siguiente paso después de validar la decisión y mapear los requisitos es entender el coste total de operación —porque es el TCO el que definirá si el ahorro de comisiones justifica la inversión y en qué horizonte temporal.
💰 Siguiente artículo: Detallamos el coste real de operar como participante directo de Pix —infraestructura, cumplimiento, operación 24/7 y la simulación de TCO que muestra cuándo se alcanza el retorno de la inversión (ROI)— en el artículo ¿Cuánto cuesta operar con Pix Directo? Infraestructura, cumplimiento y TCO real.
Lecturas relacionadas
→ Pix Direto: qué es, cómo funciona y cuándo vale la pena
→ Pix Direto vs. Pix Indireto: ¿qué modelo tiene más sentido para tu fintech?
→ SPI, DICT e Conta PI: la infraestructura detrás del Pix Direto explicada
→ ¿Cuánto cuesta operar con Pix Direto? Infraestructura, cumplimiento y TCO real
