normadata
ES
Pedir acceso →
CASO DE USO

Valida payouts de remesas LATAM antes del rail de pago

Una remesa USD -> BRL que sale con una Pix key malformada termina en reverse, customer support y un cliente molesto. El rail de pago (Stripe, dLocal, Mercado Pago, un PSP local) recibe la instruccion, intenta procesar, y la transferencia falla en la mejor de las hipotesis — o cae en limbo en la peor. Validar formato del CBU/Pix/CLABE antes de la instruccion al rail elimina esa clase entera de fallos.

Unirme a la lista de esperaLeer documentacion
EL PROBLEMA

Los reverses de cross-border tienen un costo desproporcionado

Un payout reversado por formato cuesta comisiones del rail, ticket de soporte, ciclo de FX cancelado y a veces explicacion al cliente final. Detectar el error en el cliente antes de iniciar el rail es ordenes de magnitud mas barato.

Tres rails distintos por pais, tres formatos clave
AR usa CBU (22 digitos, checksum). BR usa Pix (key puede ser CPF, CNPJ, email, telefono o random UUID). MX usa CLABE (18 digitos, Luhn-like). Una integracion cross-border hacia LATAM tiene que validar tres formatos distintos antes de cada payout — cada uno con su propio algoritmo.
Tax ID pre-flight para compliance
Muchos rails LATAM requieren tax ID del beneficiario como parte del request (CPF para Pix, CUIT para CBU). Si el tax ID viene malformado del lado del payer, el rail rechaza la instruccion. Pre-validar tax ID + cuenta evita el reverse downstream.
Customer support sobre payouts fallidos no escala
Cada payout reversado genera un ticket: el cliente final pregunta por que no recibio el dinero, el equipo de soporte tiene que diagnosticar (formato vs. cuenta inexistente vs. titular incorrecto), explicar y reintentar. A volumen, esto consume horas de support por semana.
POR QUE LAS SOLUCIONES ESTANDAR NO ALCANZAN

Por que la validacion solo en el rail llega tarde

Confiar en la validacion del rail
El rail (Stripe, dLocal, Mercado Pago) valida formato — pero recien al recibir el request. Para entonces, ya iniciaste FX, ya bloqueaste fondos, ya generaste un transaction ID. Reversarlo cuesta tiempo y dinero.
Regex por pais en el cliente
Un regex para CBU detecta longitud pero no checksum. Una Pix key tipo email pasa cualquier regex pero puede ser un email invalido. CLABE tiene un Luhn-like que regex no calcula.
Cross-checking manual de operations
Algunos equipos meten un paso manual de revision de payouts grandes. No escala, y no aplica a payouts chicos que igual fallan en volumen.
COMO NORMADATA AYUDA

Como Normadata te ayuda

Llama a verify/bank antes de armar el request al rail. CBU, CLABE, Pix key: una API, misma estructura de respuesta. Si valid=false, el payout queda en pending hasta corregir.
Complementa con verify/tax-id si el rail requiere tax ID del beneficiario (frecuente en BR/AR/MX). El gate combinado (cuenta valida + tax ID valido) elimina los reverses estructurales.
El campo normalized de la respuesta es lo que enviam al rail — la forma canonica del CBU, CLABE o Pix key que el rail espera, independientemente de como vino formateada del lado del payer.
MIRALO EN ACCION

Miralo en accion

# Validate Brazilian Pix key (CPF format) before USD->BRL remittance
$ curl -X POST api.normadata.io/v1/verify/bank \
  -H "X-API-Key: nd_a8f3b2c1d4e5f6g7h8i9j0k1l2m3n4o5" \
  -d '{"country":"BR","type":"pix","value":"111.444.777-35"}'

{
  "valid": true,
  "normalized": "11144477735",
  "identifier": {
    "type": "PIX_KEY",
    "category": "bank_account"
  }
}

# Same gate covers CLABE (MX), CBU (AR), Pix (BR)
# Skip the FX + rail leg if format is bad — no reverse, no support ticket
LIMITACIONES

Que no hace Normadata aqui

—Normadata no procesa el rail de pago, no hace FX, no es un PSP. Validamos el dato antes de que vos llames al rail.
—Normadata no confirma que la cuenta exista o pertenezca al titular nombrado. No hacemos confirmacion de titularidad bancaria, no consultamos al banco central, no validamos AML.
Ver limitaciones completas
PREGUNTAS FRECUENTES

Preguntas frecuentes

Funciona si uso Stripe, Mercado Pago o dLocal como rail?
Si, Normadata es agnostico del rail. Lo llamas vos antes de armar el request al rail (sea Stripe Connect, dLocal payouts, Mercado Pago marketplace, o un PSP local). El response te dice si el dato es estructuralmente valido.
Confirma que la cuenta pertenece al titular nombrado?
No. Validamos que el formato del CBU/Pix/CLABE sea estructuralmente correcto. Confirmacion de titularidad bancaria es otra capa, que tipicamente hace el banco o un servicio especifico de account verification, no Normadata.
Ver validadores →
Ver endpoint en docs →

Integra Normadata en tu stack

El acceso se otorga manualmente. Unite a la lista de espera y te damos acceso a la API.

Unirme a la lista de esperaLeer documentacion