Normadata vs. Trolley: validación pre-payout vs. procesamiento de pagos
No es Trolley vs. Normadata — es Normadata antes de Trolley. Validá los datos del beneficiario antes de pagar la llamada al payout provider.
Trolley (ex Payment Rails, ex Payee.io) es una plataforma de payouts globales con gestión de tax forms, compliance fiscal (1099, W-8BEN, AEOI) y KYC integrado. Normadata es una capa de validación de datos que corre ANTES del payout provider. No compiten — son capas distintas de un mismo pipeline. Normadata valida que el CBU, CLABE o tax ID del beneficiario es estructuralmente correcto antes de que Trolley intente procesar el pago y te cobre el intento.
Comparación rápida
| Aspecto | Trolley | Normadata (capa pre-payout) |
|---|---|---|
| ¿Qué hace? | Procesa pagos globales, gestión de tax forms, KYC integrado | Valida formato de datos del beneficiario ANTES del payout |
| ¿Es un payout provider? | Sí | No — es pre-payout, no payout |
| ¿Procesa dinero? | Sí | No — solo datos |
| Tax forms (1099, W-8BEN, AEOI) | Sí — producto central | No |
| Valida CBU / CLABE / tax ID LATAM formato | Validación básica de formato incluida en el flow | Sí — validación profunda multi-campo antes de enviar al payout provider |
| Costo por intento fallido | Sí — transferencia rebotada = fee + retraso | No — el error se detecta antes del envío |
| ¿Reemplaza al otro? | No | No — son capas complementarias |
¿Cuándo usar cada uno?
- Necesitás procesar pagos globales a freelancers, proveedores, creadores de contenido u otras partes.
- Tenés obligaciones de compliance fiscal (1099, W-8BEN, AEOI) y necesitás gestión de tax forms integrada al payout.
- Necesitás KYC integrado como parte del flujo de onboarding de beneficiarios.
- Querés un proveedor único que maneje el payout, el compliance fiscal y el onboarding del beneficiario.
- Tus beneficiarios LATAM ingresan CBU (Argentina) o CLABE (México) manualmente y querés detectar errores de formato antes de que Trolley rechace el pago.
- Querés validar que el CUIT, CPF o RFC del beneficiario es estructuralmente correcto antes de iniciar el proceso de payout — un tax ID malformado puede causar rechazo en el procesamiento.
- Estás procesando pagos en batch y querés normalizar y validar todos los datos del beneficiario en un paso de pre-procesamiento antes de enviar a Trolley.
- Querés normalizar el tax ID y el nombre del beneficiario a una forma canónica para detectar vos mismo duplicados en tu sistema (el mismo Juan García con CBU distinto) antes de añadirlos a tu payout provider.
El math: cuánto cuesta una transferencia rebotada
Una transferencia rebotada no es solo un retraso. Hay un fee de devolución, el costo del tiempo del equipo de operaciones para investigar el caso, la fricción con el beneficiario que no recibió su pago, y en algunos mercados LATAM un tiempo de resolución de 3-10 días hábiles. Si un 5-10% de tus beneficiarios LATAM ingresaron datos con errores de formato en el onboarding, estás pagando ese costo en cada ciclo de pago. Normadata detecta esos errores en el momento de la carga del dato — antes de que lleguen a Trolley. El costo de una llamada a Normadata es órdenes de magnitud menor al costo de un pago rechazado.
Normadata no reemplaza Trolley — es la capa anterior
Trolley mueve dinero. Normadata valida datos. Son responsabilidades completamente distintas. El patrón correcto: cuando un beneficiario ingresa sus datos (CBU, CLABE, tax ID), Normadata valida el formato en tiempo real. Si el formato es correcto, los datos llegan a Trolley. Si no, el error se muestra al beneficiario antes de guardar el dato. Trolley nunca recibe datos malformados. Vos no pagás intentos de payout que nunca podían completarse.
APIs gubernamentales tienen rate limits — cada call con dato malformado se desperdicia
Algunos flujos de payout consultan registros fiscales para validar el tax ID del beneficiario antes de pagar. Esas APIs (Receita Federal, AFIP, SAT) tienen rate limits diarios. Si el 10% de tus inputs tiene el CUIT o CPF malformado, estás quemando el 10% de tu cuota de rate limit en intentos que nunca pueden pasar. Filtrar con Normadata primero preserva tu cuota de rate limit para los datos que sí pueden procesarse.
Normadata no procesa pagos ni mueve dinero. No es un payout provider, no gestiona tax forms (1099, W-8BEN), no hace KYC regulatorio. Si necesitás procesar pagos globales con compliance fiscal integrado, Trolley es la herramienta correcta para eso. Normadata es complemento, no sustituto. También: Normadata está en beta privada sin SLA formal ni pricing post-beta definido.
Preguntas frecuentes
¿Normadata puede reemplazar Trolley?
No. Trolley procesa pagos, gestiona tax forms y hace KYC. Normadata valida datos antes de que lleguen a Trolley. Son responsabilidades completamente distintas.
¿Qué pasa si un beneficiario ingresa un CBU incorrecto en Trolley sin Normadata?
Trolley intentará procesar la transferencia. Si el CBU es inválido, el pago rebota. Hay fees de devolución, retraso en el pago al beneficiario, y tiempo de operaciones para resolver el caso. Normadata detecta el error en el momento de ingreso del dato — antes de que llegue a Trolley.
¿Trolley valida CLABE o CBU de LATAM?
Trolley incluye validación básica de formato en su flujo. La ventaja de Normadata es hacer esa validación en tiempo real en el momento de ingreso del dato — antes del submit — con validación multi-campo (tax ID + cuenta bancaria) específica para LATAM.
¿Normadata hace compliance fiscal o tax forms?
No. Normadata no gestiona 1099, W-8BEN, AEOI ni ningún formulario fiscal. Su función es validar que los datos estructurales (formato del ID, estructura de la cuenta) son correctos. El compliance fiscal es responsabilidad de Trolley o tu equipo de finanzas.