Regístrate

Caso de uso · Cumplimiento y PBC/FT

Monitorizar empresas y diligencia debida continuada

Convierta la obligación de vigilancia continuada del AMLR en un trabajo programado: reevalúe cada cliente empresarial en un ciclo basado en riesgo, vigile a diario los hechos desencadenantes y recriba las listas de sanciones automáticamente — con un rastro de auditoría que se puede mostrar a un supervisor.

Publicado el 15 de septiembre de 2026

El problema

Los equipos de cumplimiento y los OCI de fintechs, proveedores de servicios de pago, CASP, entidades de crédito y marketplaces ya ejecutan KYB en el alta: resuelven la sociedad, la criban, deciden. El hueco está en lo que pasa después de la aprobación. El AMLR (Reglamento (UE) 2024/1624), aplicable desde el 10 de julio de 2027, es explícito en que el expediente de un cliente empresarial debe mantenerse al día: revisado en un ciclo basado en riesgo, actualizado cuando algo cambia. Las transposiciones vigentes de la AMLD5/6 ya apuntan en la misma dirección, igual que la Ley 10/2010 para los sujetos obligados en España.

En la práctica, la revisión periódica suele ser un ejercicio anual de hoja de cálculo: exportar el listado, revisar cada sociedad a mano. Un administrador cesa o un cliente entra en concurso a los ocho meses del ciclo, y nadie se entera hasta la siguiente revisión programada — o hasta que un supervisor pide el rastro de auditoría y no existe.

Esta página describe lo que pide la obligación en términos generales, no es asesoramiento legal; véase el calendario de cumplimiento del AMLR (en inglés) para las fechas y los umbrales.

El patrón

Se ejecutan las mismas comprobaciones que en el alta, pero en un calendario en lugar de una sola vez. Cuatro endpoints hacen el trabajo, más una cosa que se guarda en su propio sistema:

  • 1. Revisión periódica programada. Reevalúe cada cliente con POST /companies/lookup (hasta 100 elementos por llamada) y compare status, dissolution_date, address, legal_form y previous_names con lo guardado en el alta — anual para clientes de riesgo bajo, trimestral para los de riesgo alto.
  • 2. Vigilancia por hechos desencadenantes. POST /monitor envía webhooks firmados con HMAC-SHA256 (X-Prometiam-Signature) para clientes en todos los países en producción excepto Francia y Chile, con México limitado a las entidades con LEI y Argentina sin alerta de disolución: España por defecto vigila corporate_event, status_change y sanctions_match; Irlanda y Polonia (a nivel empresa) vigilan por defecto status_change, dissolution y sanctions_match. Para clientes españoles, franceses y británicos, un barrido diario con GET /company-events/search?date_from= capta disolución, insolvencia, cambio de administradores, capital, denominación y domicilio en su lugar.
  • 3. Recribado de sanciones. GET /sanctions/changes?since= informa de lo que se ha dado de alta, de baja o actualizado en las listas desde la última ejecución; POST /sanctions/screen vuelve a cribar la cartera que toca revisar en ese ciclo, hasta 50 nombres por llamada.
  • 4. Insolvencia. POST /insolvency/check cubre insolvencia de empresas en dieciséis mercados (FR, DE, GB, AT, CH, NO, FI, US, NL, DK, HR, SE, ES, LV, EE, SG) en una sola llamada por lotes, hasta 5 anuncios por elemento. Alemania, Austria, Estados Unidos y Países Bajos no tienen un registro mercantil detrás de estos anuncios, así que ahí es la única señal disponible. Finlandia, Dinamarca, Croacia, Suecia y Suiza tienen fichas de empresa (solo datos de empresa: sin administradores, con eventos de cambio del registro y monitorización) y sus anuncios se vinculan por identificador de empresa (número CVR en Dinamarca, MBS en Croacia, organisationsnummer en Suecia, UID en Suiza cuando el aviso nombra el UID del deudor). Letonia y Estonia también son solo datos de empresa y sus anuncios se vinculan por número de registro (Letonia, 11 dígitos) o código de registro (Estonia, solo declaraciones de quiebra de empresas aún en el registro). Eslovaquia y Estados Unidos también son solo datos de empresa (con eventos de cambio del registro y monitorización), pero sin anuncios de insolvencia vinculados a la ficha: su quiebra figura en el estado de la empresa. Los concursos de acreedores de España (BORME, enlazados por NIF; no se sirven el juez ni el administrador concursal) se comprueban igual, y GET /search sigue sirviéndolos.
  • 5. Rastro de auditoría. Guarde cada respuesta con su match_score, el threshold usado y la fecha de revisión — el registro que un supervisor pedirá ver.
# 1. Reevaluar hasta 100 clientes por llamada y comparar con el expediente guardado
curl -X POST 'https://api.prometiam.com/functions/v1/risk-api/companies/lookup' \
  -H 'Authorization: Bearer rk_live_...' -H 'Content-Type: application/json' \
  -d '{"items":[{"country":"ES","nif":"B12345674"},{"country":"ES","company_number":"A28015865"}]}'

# 2. ¿Qué se ha movido en las listas de sanciones desde la última ejecución?
curl 'https://api.prometiam.com/functions/v1/risk-api/sanctions/changes?since=2026-08-15' \
  -H 'Authorization: Bearer rk_live_...'

# 3. Insolvencia de empresas en los dieciséis mercados cubiertos, mismo formato por lotes
curl -X POST 'https://api.prometiam.com/functions/v1/risk-api/insolvency/check' \
  -H 'Authorization: Bearer rk_live_...' -H 'Content-Type: application/json' \
  -d '{"items":[{"country":"FR","company_number":"552032534"},{"country":"GB","name":"Example Ltd"}]}'

Dos particularidades. Los registros franceses pueden devolver status: non_diffusible cuando el INSEE ha restringido la publicación de la identidad de esa entidad; trátelo como desconocido, no como un cambio de estado. Y GET /sanctions/changes es un aviso, no una consulta: informa de lo que se ha movido en las listas, no de a qué clientes afecta, así que el patrón práctico es recribar la cartera que toca en ese ciclo cada vez que el feed muestra actividad. El cribado PEP sigue siendo beta, solo España, sin familiares ni allegados, así que un resultado PEP sin coincidencias no equivale por sí solo a una determinación conforme al GAFI. Para el detalle del cribado por lotes, véase la edición en inglés de ongoing due diligence.

Un ejemplo real

El trabajo de revisión: reevaluar por lotes, comparar, recribar según corresponda, comprobar insolvencia y dejar constancia de cada resultado. Un planificador — cron, un Cloudflare Cron Trigger o un worker de cola — llama a review() una vez al día con los clientes que tocan según el calendario.

import os, requests
from datetime import date

API = 'https://api.prometiam.com/functions/v1/risk-api'
HEAD = {'Authorization': f'Bearer {os.environ["PROMETIAM_API_KEY"]}'}
CAMPOS_VIGILADOS = ('status', 'dissolution_date', 'address', 'legal_form', 'previous_names')
DOCE_MERCADOS = {'FR', 'DE', 'GB', 'AT', 'CH', 'NO', 'FI', 'US', 'NL', 'DK', 'HR', 'SE'}

def review(clientes, ultima_ejecucion):
    # 1. Reevaluar hasta 100 a la vez; comparar los campos vigilados con el registro guardado
    for i in range(0, len(clientes), 100):
        lote = clientes[i:i + 100]
        items = [{'country': c['country'], 'company_number': c.get('company_number'), 'nif': c.get('nif')} for c in lote]
        r = requests.post(f'{API}/companies/lookup', json={'items': items}, headers=HEAD).json()
        for guardado, resultado in zip(lote, r['data']):
            empresa = resultado.get('company') or {}
            cambios = {f: empresa.get(f) for f in CAMPOS_VIGILADOS if empresa.get(f) != guardado.get(f)}
            auditar(guardado, 'lookup', resultado, cambios or None)

    # 2. Solo recribar si una lista de sanciones se ha movido desde la última ejecución
    cambios_listas = requests.get(f'{API}/sanctions/changes', params={'since': ultima_ejecucion}, headers=HEAD).json()
    if cambios_listas.get('data'):
        nombres = [c['razon_social'] for c in clientes]
        lote = requests.post(f'{API}/sanctions/screen', headers=HEAD,
                              json={'names': nombres, 'threshold': 85, 'group': 'entity'}).json()
        for guardado, resultado in zip(clientes, lote['data']):
            auditar(guardado, 'sanctions', resultado, threshold=85)

    # 3. Insolvencia de empresas, solo los dieciséis mercados
    vigilados = [c for c in clientes if c['country'] in DOCE_MERCADOS]
    if vigilados:
        items = [{'country': c['country'], 'company_number': c['company_number']} for c in vigilados]
        r = requests.post(f'{API}/insolvency/check', json={'items': items}, headers=HEAD).json()
        for guardado, resultado in zip(vigilados, r['data']):
            if resultado['status'] == 'found':
                auditar(guardado, 'insolvency', resultado)

def auditar(cliente, tipo, respuesta, cambios=None, threshold=None):
    # 4. Solo apéndice: la respuesta bruta, el score/threshold usado y la fecha de hoy
    db.review_log.insert({'cliente_id': cliente['id'], 'tipo': tipo, 'respuesta': respuesta,
                           'match_score': respuesta.get('best_match_score'), 'threshold': threshold,
                           'campos_cambiados': cambios, 'revisado_el': date.today().isoformat()})

42 líneas incluyendo las importaciones. db y las filas de clientes son su propio almacén — Prometiam no tiene el concepto de "su cartera"; resuelve, criba y comprueba lo que se le envíe.

Qué se devuelve

Cada comprobación devuelve un estado sobre el que ramificar, más el detalle que un rastro de auditoría debe conservar:

  • POST /companies/lookup — status (found / not_found / error / timeout) y, cuando se encuentra, el objeto de empresa habitual: status, dissolution_date, address, legal_form, previous_names, y un match_score normalmente nulo aquí porque la llamada resuelve por identificador.
  • POST /sanctions/screen — status (match / clear / error / timeout) por nombre, hits[], hit_count, distinct_entities y un best_match_score — regístrelo junto al threshold configurado.
  • POST /insolvency/check — status (found / none / error / timeout), hasta 5 notices[] del más reciente al más antiguo, y latest_filing_date. none significa que no hay anuncio de empresa en los dieciséis mercados cubiertos, no que la sociedad sea solvente.
  • Webhooks de POST /monitor — alert_type (corporate_event / status_change / dissolution / sanctions_match), event_date, un objeto detail y webhook_status.
Captura del panel de clientes: una lista de empresas monitorizadasCaptura del panel de clientes: una lista de empresas monitorizadas
POST /monitor en el panel: la lista de vigilancia y qué se vigila de cada empresa. La monitorización cubre todos los países activos salvo Francia y Chile; la coincidencia de sanciones es beta. Se muestra una cuenta de demostración. Ábrelo en el panel

Ajuste de precio

Tomemos una cartera de 5.000 clientes. La revisión anual son 5.000 elementos de POST /companies/lookup al año — insignificante frente a una cuota mensual. El recribado trimestral son 5.000 × 4 = 20.000 elementos de POST /sanctions/screen al año, con picos de hasta 5.000 en un solo mes. El factor real es el barrido diario: 1.500 nombres españoles, franceses y británicos consultados a diario con GET /company-events/search ronda las 45.000 llamadas al mes, es decir, 90.000 créditos a 2 créditos por llamada. Con un pico de recribado de fin de trimestre encima (hasta 5.000 nombres a 3 créditos, 15.000), el mes más cargado queda cerca de los 105.000 créditos — por encima de Scale (99,99 € al mes, 50.000 créditos al mes, 300 peticiones/minuto), así que conviene negociar una asignación Enterprise o pasar el barrido a webhooks. La misma forma con 500 clientes son unos 9.000 créditos del barrido más un pico de recribado de 1.500, 10.500 en el mes más cargado: el límite de Professional (29,99 € al mes, 10.000 créditos al mes, 120 peticiones/minuto), con Scale cómodamente por encima.

Un límite más a tener en cuenta: POST /monitor limita las suscripciones activas por plan (Free 3, Starter 25, Professional 250, Scale 2.500). Una cartera de 5.000 clientes con todos los nombres de un país monitorizado (todos los países en producción excepto Francia y Chile, con México limitado a las entidades con LEI y Argentina sin alerta de disolución) bajo vigilancia por webhook supera incluso el tope de Scale (99,99 € al mes); ponga bajo webhook el subconjunto de mayor riesgo y deje el resto al barrido diario o a un paso programado por GET /search.

Límites de alcance, declarados con claridad

  • Los anuncios de insolvencia son solo de empresas, en dieciséis mercados (FR, DE, GB, AT, CH, NO, FI, US, NL, DK, HR, SE, ES, LV, EE, SG). Los concursos de acreedores de España están incluidos; GET /search sigue sirviéndolos.
  • La vigilancia por webhook (POST /monitor) cubre todos los países en producción excepto Francia y Chile, con México limitado a las entidades con LEI y Argentina sin alerta de disolución, con un límite de suscripciones activas por plan.
  • El cribado de sanciones es beta. El cribado PEP es beta, solo España, y no incluye familiares ni allegados — un resultado sin coincidencias no equivale por sí solo a una determinación PEP conforme al GAFI.
  • Irlanda es a nivel empresa: no hay administradores que reevaluar todavía, así que la comparación periódica se limita al registro de la sociedad.
  • Noruega solo tiene eventos de cambio del registro, desde el 14 de octubre de 2026 (sin boletín) y queda fuera de los países que cubre POST /monitor, así que sus clientes reciben la comparación periódica de POST /companies/lookup más los controles de sanciones e insolvencia, sin el barrido diario ni webhooks.
  • Nada de esto es asesoramiento legal. Describe lo que devuelve la API; si un programa cumple el AMLR, la AMLD5/6 o la Ley 10/2010 es una decisión de su función de cumplimiento — véase el calendario de cumplimiento del AMLR (en inglés).

Preguntas frecuentes

¿Qué significa "diligencia debida continuada" bajo el AMLR?
El AMLR (Reglamento (UE) 2024/1624, aplicable desde el 10 de julio de 2027) trata el expediente de un cliente empresarial como algo que hay que mantener al día, no como un filtro de una sola vez: revisarlo en un ciclo basado en riesgo y actuar ante hechos desencadenantes como una disolución o una nueva coincidencia en sanciones. Esto describe la obligación en términos generales, no es asesoramiento legal — véase el calendario de cumplimiento del AMLR.

¿Con qué frecuencia hay que reevaluar a un cliente empresarial?
Una cadencia habitual basada en riesgo es anual para clientes de riesgo bajo y trimestral para los de riesgo alto, repitiendo las mismas comprobaciones que se hicieron en el alta. La cadencia exacta es una decisión de su función de cumplimiento.

¿Se puede automatizar el recribado de sanciones?
GET /sanctions/changes?since= informa de lo que se ha dado de alta, de baja o actualizado en las listas desde la última ejecución, y POST /sanctions/screen vuelve a cribar hasta 50 nombres por llamada. El cribado de sanciones es beta; el cribado PEP es beta, solo España, y no incluye familiares ni allegados, así que un resultado sin coincidencias no equivale por sí solo a una determinación conforme al GAFI.

¿Cómo recibo el aviso de que una empresa ha cambiado?
Se da de alta la empresa con POST /monitor y la API envía un webhook firmado con HMAC-SHA256 cuando cambia su estado, se disuelve, aparece una coincidencia de sanciones (beta) o hay un evento societario (en España, los actos del BORME). Starter incluye 25 empresas vigiladas, Professional 250 y Scale 2.500, con webhooks en todos los planes.

¿La vigilancia continuada funciona igual en todos los países?
No. Los webhooks de POST /monitor cubren todos los países en producción excepto Francia y Chile, con México limitado a las entidades con LEI y Argentina sin alerta de disolución. GET /company-events/search cubre España, Francia y Reino Unido, más eventos de cambio del registro para todos los demás países en producción excepto Chile. Irlanda, Polonia y Noruega no tienen ninguno antes del 14 de octubre de 2026, Argentina se lee cada mes (ninguno antes del 28 de octubre de 2026) y México cubre solo las entidades con LEI. Noruega solo tiene eventos de cambio del registro, desde el 14 de octubre de 2026 (sin boletín), y POST /monitor la cubre; la insolvencia se comprueba aparte y la comparación periódica de POST /companies/lookup más los controles de sanciones e insolvencia. Irlanda es a nivel empresa, sin administradores que reevaluar todavía.

¿Qué ocurre si un lote de revisión supera la cuota disponible?
POST /companies/lookup, POST /sanctions/screen y POST /insolvency/check cuentan cada elemento como una llamada. Un lote mayor que lo que queda del plan se rechaza de entrada con un 429 (batch_exceeds_quota) y max_items_now, de modo que la llamada se puede redimensionar en lugar de perder resultados parciales.

Relacionados