Comprobar una dirección a mano lleva un minuto. Pero cuando cientos de clientes al día pasan por tu exchanger o por tu bot, comprobar cada uno manualmente es imposible. Aquí es donde entra la API de AML: una interfaz programática que toma una dirección y devuelve un veredicto en una fracción de segundo. En esta lección desglosamos cómo funciona la API por dentro, cómo integrarla en el flujo de fondos entrantes y por qué un servicio serio no puede operar sin automatización.
Una API (Application Programming Interface, interfaz de programación de aplicaciones) es el «enchufe» donde tu programa conecta una petición y recibe una respuesta de vuelta. En lugar de abrir un sitio web, pegar una dirección en un campo y leer un informe con los ojos, tu código envía la dirección por la red y recibe una respuesta estructurada, normalmente en formato JSON. La diferencia es como ir al pozo con un cubo cada vez frente a tener cañerías dentro de casa.
La idea clave: la entrada es una dirección (y una red), la salida es un veredicto. El veredicto casi siempre consta de tres cosas: una puntuación de riesgo numérica (0–100), una categoría de riesgo (por ejemplo, mixer, sanctions, scam, exchange) y una recomendación (aceptar / comprobar manualmente / rechazar). Todo lo demás es detalle: cuotas de exposición, una lista de contactos de riesgo, la profundidad de saltos.
Técnicamente una petición es una llamada HTTP ordinaria. Envías parámetros y una clave de autorización al endpoint del servicio. Esquemáticamente tiene este aspecto:
Petición: GET /v1/check?address=0xABC...&network=eth con la cabecera Authorization: Bearer YOUR_KEY.
Respuesta (simplificada):
{ "score": 78, "risk": "high", "category": "mixer", "exposure": { "mixer": 41, "exchange": 22, "unknown": 37 }, "verdict": "reject" }
Tu código lee el campo verdict y el campo score, y decide qué hacer a continuación en función de ellos. Sin «ojos» y sin lectura manual: todo se convierte en una bifurcación dentro del programa.
Trabajemos con un escenario típico: un cliente quiere cambiar USDT por rublos y te envía la dirección desde la que llegará la cripto (o la dirección de depósito que le diste, a la que ya ha enviado los fondos). Un servicio adecuado comprueba la dirección antes de entregar dinero/rublos. Aquí está el flujo paso a paso.
score < 40 — aprobación automática, la operación continúa. Si 40–74 — pasa a un operador para revisión manual. Si ≥ 75 o la categoría es sanctions/mixer — rechazo automático y retención de los fondos.Hay dos formas de obtener datos: sondeo (polling) —tú mismo preguntas «¿y bien, ya ha llegado?» cada N segundos— y un webhook —el servicio llama a tu puerta por sí mismo cuando ocurre un evento—. Un webhook es más eficiente: registras tu URL con el proveedor, y este envía una petición POST cuando, por ejemplo, una nueva transacción ha pasado por una dirección vigilada o su estado de riesgo ha cambiado.
Cada llamada a la API cuesta dinero o consume cuota. Por eso una integración bien pensada siempre incluye: caché (no compruebes la misma dirección diez veces por minuto: guarda el resultado durante unas horas), un límite de tasa (rate limit) (para que no llegues al techo de tu plan), y una reserva para el bot (si la misma clave sirve al sitio y al bot, aparta lo suficiente para que el sitio no «se coma» toda la cuota). Esta es exactamente la lógica implementada en los sistemas reales: caché + tope + reserva.
Este material tiene fines educativos. Los nombres de campos y los formatos son ilustrativos y dependen del proveedor concreto.