Verificación de la cuenta
Aloha pide dos verificaciones antes de dejar que una cuenta mueva dinero, y son dos trámites distintos: Verificar Identidad, que es sobre la persona que está detrás de la cuenta, y la Verificación Comercial, que es sobre la empresa. No se hacen en el mismo momento, no piden los mismos datos y ninguna de las dos adelanta a la otra.
La que frena no es la que se supone
Lo que se espera es que una cuenta recién abierta tenga las dos pendientes. No es así: Verificar Identidad ya viene hecha.
El alta no crea la cuenta hasta que la identidad está aprobada. Se verifica primero y se registra después: si la comprobación no salió aprobada, el alta se rechaza y no llega a existir ninguna cuenta. Por eso la cuenta nace con ese paso resuelto y con la fecha en que se resolvió, y con la Verificación Comercial sin empezar.
La consecuencia práctica es la que importa al integrar: en una cuenta nueva, lo que devuelve el rechazo casi siempre es KYB_VERIFICATION_REQUIRED, no KYC_VERIFICATION_REQUIRED. Quien depure una integración nueva buscando un problema de identidad va a buscar en el sitio equivocado.
Eso no vuelve irrelevante a Verificar Identidad —hay cuentas que la tienen rechazada o en revisión, y hay operaciones que solo exigen esa—, pero sí decide dónde mirar primero.
Verificar Identidad
Comprueba a la persona, no a la empresa. Son cuatro cosas a la vez: se lee el documento de identidad, se coteja la cara con la foto del documento, se comprueba que quien lo presenta está delante de la cámara en ese momento, y se criba el nombre contra listas.
Cuánto tarda: la decisión es automática y llega en la misma sesión, salvo que caiga en revisión manual.
Hay tres desenlaces y solo uno deja seguir:
| Resultado | Qué significa |
|---|---|
| Aprobada | El paso queda hecho, con su fecha |
| Rechazada | Se puede abrir una sesión nueva y repetirla. El motivo queda guardado y se consulta |
| En revisión manual | Ni aprobada ni rechazada: la decisión automática no alcanzó y la revisa una persona |
La revisión manual es el estado que más desconcierta, porque no se puede reintentar: pedir una sesión nueva desde ahí se rechaza por tener una ya en curso. Lo único que se puede hacer es esperar la decisión.
Cuando el rechazo sí ocurre, el motivo no es genérico: dice cuál de las cuatro comprobaciones falló —documento, cotejo de cara, prueba de vida o listas— y con qué advertencia. Eso es lo que hay que leer antes de repetir, porque repetir sin cambiar nada suele terminar igual.
Verificación Comercial
Es la que queda pendiente y la que hay que hacer. Verifica a la empresa: qué es, quién la controla y con qué papeles se acredita.
Son cuatro pasos y el orden importa:
- Abrir la solicitud. Queda en borrador. Abrirla exige tener hecha Verificar Identidad, y es el único paso de este trámite que la exige.
- Cargar los datos. Cuáles, depende de si la cuenta es de una empresa o de una persona —abajo está el detalle—. Los datos se guardan sobre la cuenta, no sobre la solicitud.
- Adjuntar al menos un documento. Uno es el mínimo. Se aceptan PDF, JPG y PNG, hasta 10 MB cada uno, y cada documento se declara por tipo, de un catálogo que separa los de la persona de los de la empresa: documento de identidad, comprobante de domicilio, constancia fiscal, acta constitutiva, estado de cuenta bancario, documento de un beneficiario final, poder notarial, y un tipo genérico para lo que no encaje en ninguno.
- Enviarla a revisión. El envío comprueba antes que estén los datos y que haya al menos un documento; si falta cualquiera de las dos cosas se rechaza ahí mismo, sin llegar a la revisión.
Qué se pide, según el tipo de cuenta
- Una cuenta de empresa declara su razón social, su forma jurídica, su identificador fiscal, el país de constitución y el domicilio registrado —y el operativo aparte, si no coincide—, más el nombre y el cargo de su representante legal. Opcionalmente se declaran el nombre comercial, la fecha de constitución, a qué se dedica, el volumen mensual esperado, un teléfono y un correo. Y declara a sus beneficiarios finales y personas con control, cada uno con nombre y apellido obligatorios y con su porcentaje de participación, fecha de nacimiento, identificador fiscal, documento y domicilio.
- Una cuenta de persona declara nombre y apellido, fecha de nacimiento, nacionalidad, identificador fiscal y domicilio completo. Opcionalmente, el tipo y número de documento con su vencimiento, teléfono, correo, ocupación y rango de ingresos, y si es una persona políticamente expuesta.
El porcentaje de participación de un beneficiario final se declara en números enteros. Un 33,5 % no se puede expresar.
Cuánto tarda y qué avisa
La revisa una persona, y Aloha no promete un plazo para la primera revisión: avisa por correo cuando hay decisión. Al enviarla no llega ningún acuse, así que el silencio inmediato después de enviar es lo normal y no significa que no se recibió.
Los correos que sí salen son tres: cuando se aprueba, cuando se rechaza y cuando se pide una corrección. Los dos últimos llevan el motivo dentro.
Rechazo y corrección no son lo mismo
Se parecen —los dos devuelven la pelota— pero se resuelven distinto:
| Situación | Qué hay que hacer |
|---|---|
| Se pide una corrección | La solicitud vuelve a borrador con las notas de qué ajustar. Se corrige, se vuelve a enviar, y los documentos ya adjuntos siguen ahí |
| Se rechaza | Hay que abrir una solicitud nueva. Los datos de la empresa o de la persona se conservan; los documentos, no: van pegados a la solicitud anterior y hay que adjuntarlos otra vez |
El correo de rechazo trae además una promesa concreta que conviene aprovechar: un reenvío ya corregido se revisa el mismo día.
Y mientras una solicitud está enviada o en manos de quien la revisa, no se puede abrir otra ni adjuntarle documentos. Solo se puede esperar.
Qué deja de funcionar mientras la Verificación Comercial está pendiente
La Verificación Comercial pendiente bloquea crear, y nada más. Lo que ya existe se sigue consultando y se sigue cancelando con normalidad — desde el panel y desde la API por igual.
Lo que se bloquea:
- Crear una Solicitud de Pago, de una en una o en carga masiva — que es lo que en la práctica deja a la cuenta sin poder cobrar.
- Ordenar un Retiro y ordenar un Envío, incluidos los dos pasos del código de un solo uso que pide un Envío.
- Registrar una Cuenta Bancaria y registrar un Beneficiario — es decir, ni siquiera se puede dejar preparado el destino al que algún día va a salir el dinero.
Lo que no se bloquea, y suele sorprender: emitir una Clave API sí se puede. Eso solo exige Verificar Identidad, que ya está hecha. Una cuenta pendiente puede integrarse entera, registrar sus webhooks y pedir cotizaciones; lo único que no puede es crear el cobro.
Las dos negativas responden 400, no 403. Es deliberado y hay que saberlo de antemano, porque un cliente que clasifique por estado va a meter estos dos rechazos en el mismo cajón que un cuerpo mal formado. Lo que los distingue es el code: KYC_VERIFICATION_REQUIRED y KYB_VERIFICATION_REQUIRED, cada uno con un meta que dice en qué punto está el paso que falta —el estado y la fecha, y el motivo del rechazo cuando lo hay—. Están en la tabla de Errores.
Tres verificaciones que no se sustituyen
Esta página cubre dos trámites. Hay más, y comparten la palabra sin compartir nada más:
- Verificar la Cuenta Bancaria es otro trámite, con sus propios documentos, y hace falta para todo Retiro —Instantáneo o Regular, ordenado a mano o automático—. Un Envío no la pide, porque su destino es un Beneficiario. Tener la cuenta verificada no verifica la Cuenta Bancaria.
- Activar la Cuenta Bancaria USD es una revisión aparte, con su propio contrato y sus propios documentos. Un documento presentado aquí no vale allá, y al revés.
- Cada Ambiente se verifica por su cuenta. Una cuenta verificada en Sandbox no arrastra nada a Producción.
En la API
En la API externa, dos de las dieciséis operaciones exigen la cuenta verificada, y las dos exigen las dos verificaciones:
| Operación | Ruta | Exige |
|---|---|---|
| Crear una Solicitud de Pago | POST /v1/payment-links | Las dos |
| Crear un cobro con tarjeta | POST /v1/cards/payment-links | Las dos |
Las otras catorce no comprueban nada de esto. Consultar y cancelar una Solicitud de Pago, administrar endpoints de webhook, listar Billeteras y medios de pago y pedir una cotización funcionan igual con la Verificación Comercial pendiente.
Desde la API del panel, bajo /api/v1/clients, son doce las operaciones que exigen una verificación o las dos:
| Operación | Ruta | Exige |
|---|---|---|
| Crear una Solicitud de Pago | POST /api/v1/clients/payment-links | Las dos |
| Ordenar un Retiro o un Envío | POST /api/v1/clients/payouts | Las dos |
| Confirmar el código de un Envío | POST /api/v1/clients/payouts/verify-otp | Las dos |
| Reenviar el código de un Envío | POST /api/v1/clients/payouts/resend-otp | Las dos |
| Registrar una Cuenta Bancaria | POST /api/v1/clients/bank-accounts | Las dos |
| Registrar un Beneficiario | POST /api/v1/clients/beneficiaries | Las dos |
| Carga masiva de Solicitudes de Pago | POST /api/v1/clients/payment-links/bulk-upload | Las dos |
| Emitir una Clave API | POST /api/v1/clients/api-keys | Verificar Identidad |
| Crear un Rol | POST /api/v1/clients/roles | Verificar Identidad |
| Estadísticas de usuarios | GET /api/v1/clients/users/stats | Verificar Identidad |
| Habilitar el cobro con tarjeta | POST /api/v1/clients/cards/account | Verificar Identidad |
| Abrir la Verificación Comercial | POST /api/v1/clients/verification/start | Verificar Identidad |
De esas doce, once son de creación y una es de lectura: las estadísticas de usuarios son la única consulta de esa API que una verificación puede rechazar. Fuera de ella la verificación condiciona lecturas también: las rutas públicas de checkout y de tienda no llegan a resolver el comercio mientras no esté verificado, así que lo que se consulte por ahí vuelve como que no existe.
El trámite en sí se lleva con estas operaciones, también bajo /api/v1/clients:
| Operación | Ruta | Permiso |
|---|---|---|
| Estado de Verificar Identidad | GET /api/v1/clients/kyc/status | — |
| Abrir una sesión de identidad | POST /api/v1/clients/kyc/initiate | — |
| Estado de la Verificación Comercial | GET /api/v1/clients/verification/status | — |
| Datos ya cargados | GET /api/v1/clients/verification/data | — |
| Abrir la solicitud | POST /api/v1/clients/verification/start | submit_kyb_verifications |
| Guardar los datos de la persona | POST /api/v1/clients/verification/personal-data | submit_kyb_verifications |
| Guardar los datos de la empresa | POST /api/v1/clients/verification/business-data | submit_kyb_verifications |
| Adjuntar un documento | POST /api/v1/clients/verification/documents/{request} | submit_kyb_verifications |
| Enviarla a revisión | POST /api/v1/clients/verification/submit/{request} | submit_kyb_verifications |
Consultar el estado de cualquiera de las dos no exige ningún Permiso: cualquier usuario de la cuenta puede mirar en qué punto está. Avanzar el trámite sí lo exige, y el Permiso es el mismo para los cinco pasos.
Esa API es la que usa el panel; no es una superficie de integración y no se documenta aquí. Se nombra para poder emparejar lo que se ve en pantalla con la operación que hay detrás. La API externa no lleva el trámite: ni lo consulta ni lo avanza.
Relacionado
- Qué es Aloha — dónde encaja este requisito en el recorrido de una cuenta.
- Errores — los dos códigos, su estado y qué hacer con cada uno.
- Inicio rápido — la primera llamada que choca contra esto, y por qué no es un problema de la clave.
- Ambientes y Sandbox — por qué verificar en uno no verifica en el otro.
- Cuenta bancaria USD — la otra revisión con documentos, que es aparte.
- Retiros — la verificación de la Cuenta Bancaria, que también es aparte.
- Glosario — la definición de cada término de esta página.
Updated 26 days ago
