Cumplimiento
Lanzamiento de la plataforma en verano de 2026 · Acceso de prueba abierto desde hoy
Compliance Platform
Cribado de comercio y sanciones con pruebas.
CN / TARIC
Listas de sanciones
Screening Cases
Pagos ISO 20022
API + MCP
Sin relación con la Comisión Europea. No sustituye las fuentes oficiales ni las decisiones de las autoridades competentes.
v6 · 20 de mayo de 2026
02 · Desafío
Lo difícil no es el cribado. Lo difícil es defender el resultado.
El trabajo de cumplimiento falla cuando una respuesta no se puede reproducir, documentar con fuente ni explicar a un auditor.
- Las listas de sanciones, las medidas TARIC y los registros de entidades están repartidos entre decenas de reguladores. Combinarlos manualmente consume tiempo de los revisores.
- La mayoría de las herramientas dan una respuesta sí/no. Los auditores quieren el enlace a la fuente, la marca de tiempo y el razonamiento del revisor.
- Alias, transliteraciones y variantes locales de nombres convierten un «sin coincidencias» limpio hoy en una coincidencia perdida mañana.
- Las comprobaciones TARIC, los cribados de entidades y las verificaciones de buques se acumulan en hojas de cálculo y correos — no como un único expediente auditable.
- Cuando una herramienta marca una coincidencia, los revisores no siempre ven por qué. Eso hace que la decisión sea difícil de defender en una auditoría.
- Los ingenieros que crean automatización interna suelen verse forzados a hacer scraping de la misma interfaz que usan los equipos de cumplimiento.
Brecha en la defensa de auditoría
1
Muchas fuentes oficiales
Listas de sanciones, medidas TARIC, registros de entidades
2
Combinación manual
Hojas de cálculo, capturas de pantalla, hilos de correo
?
Decisión bajo auditoría
«¿Dónde están las pruebas?»
Un resultado defendible mantiene unidos los datos, la fuente, los parámetros, el revisor y el tiempo.
03 · Público objetivo + posicionamiento
Las herramientas de cumplimiento se diseñaron para bancos de nivel 1. El trabajo de cumplimiento ocurre en todas partes excepto allí.
La misma presión regulatoria alcanza ahora a equipos sin un departamento de cumplimiento propio.
- Las herramientas de cumplimiento surgieron tras el 11 de septiembre y maduraron en bancos y consultoras Big Four. Siguen costando y configurándose en consecuencia.
- La misma presión regulatoria, un campo mucho más amplio: corporaciones multinacionales, bancos regionales y de pymes, empresas de logística, agentes de aduanas, aeropuertos regionales, grupos operativos de policía, notarios y servicios comunitarios.
- Estos equipos no tienen un departamento de cumplimiento propio. El trabajo recae en operaciones, jurídico o la dirección — junto al trabajo diario.
- Necesitan pruebas de cribado tan defendibles como las de un banco de nivel 1 — pero no pueden justificar una licencia de seis cifras ni una integración de seis meses.
- Necesitan acceso allí donde trabajan: una herramienta web para el jurista, una API para el ingeniero, un servidor MCP para el agente de IA.
- La larga cola del cumplimiento es órdenes de magnitud mayor que el núcleo bancario / Big Four — la misma exposición regulatoria, muchas menos herramientas, ningún proveedor serio que los atienda.
La larga cola del cumplimiento
Núcleo bancario / Big Four
Corporaciones multinacionales
Bancos regionales y de pymes
Empresas de logística
Agentes de aduanas
Aeropuertos regionales
Grupos operativos de policía
Notarios
Servicios comunitarios
La misma presión. Muchas menos herramientas. Ningún proveedor serio para todo el espectro.
04 · Funcionalidades principales
Cumplimiento defendible — sin equipo de cumplimiento propio.
La plataforma transforma las operaciones diarias de cribado en decisiones listas como pruebas.
- Obtenga una única respuesta vinculada a la fuente a la pregunta «¿Se puede enviar, procesar o tramitar esto?» — abarcando medidas TARIC/CN, sanciones y registros de entidades, no tres herramientas separadas.
- Genere pruebas defendibles como subproducto del trabajo. Cada control recibe automáticamente marca de tiempo, vínculo a la fuente y asignación al revisor — sin preparación de auditoría aparte.
- Detecte lo que la revisión manual pasa por alto. Las coincidencias de alias, las variantes de transliteración y los patrones de nombres locales sacan a la luz candidatos que un escaneo sí/no omitiría.
- Agrupe los controles relacionados en un único expediente. Las búsquedas TARIC, los cribados de entidades y las verificaciones de buques viajan juntos — un artefacto auditable por decisión.
- Úselo donde se realiza el trabajo. El jurista en la aplicación web, el ingeniero por API, el agente de IA por MCP — los mismos datos, las mismas fuentes, el mismo rastro de auditoría.
- Empiece hoy en el espacio de prueba. Sin mínimo de seis cifras, sin integración de seis meses, sin exigir un departamento de cumplimiento.
Estado del espacio de trabajo, servicios activados, preparación y controles recientes en una vista coherente.
05 · Canales
Tres interfaces, una única fuente de verdad.
Revisor, ingeniero y agente de IA usan por debajo los mismos datos.
- Web UI — la interfaz completa de cribado para uso directo del revisor. Los mismos datos, las mismas pruebas, el mismo rastro de auditoría que en los otros canales.
- API — endpoints REST para cada flujo de trabajo disponible en la interfaz. Incorpore cumplimiento en la incorporación KYC, la diligencia debida de proveedores, la supervisión de transacciones o cualquier automatización interna.
- MCP Server — expone los flujos de cribado como herramientas nativas para agentes de IA. Cualquier cliente compatible con MCP (Claude, ChatGPT Agents, personalizado) puede invocar controles y recibir pruebas con vínculo a la fuente.
- Un rastro de auditoría. Un control ejecutado por API aterriza en el mismo registro Screening Cases que un control por interfaz. El revisor ve ambos. El auditor ve ambos.
- Una fuente de verdad. Los tres canales consultan los mismos datos de sanciones, las mismas medidas TARIC, la misma lógica de coincidencia aproximada. Sin divergencia entre «versión API» y «versión interfaz».
- API y MCP son de primera clase, no exclusivos para enterprise. Disponibles en el espacio de prueba hoy, igual que la Web UI.
Ecosistema
Web UI
Interfaz del revisor
REST API
Automatización interna
MCP Server
Herramientas para agentes
Datos unificados
Sanciones · TARIC · coincidencia aproximada
Un rastro de auditoría
Registro Screening Cases
Sin divergencia entre interfaz y API — las mismas fuentes, la misma lógica de coincidencia aproximada, el mismo artefacto del expediente.
06 · Controles de códigos TARIC / CN
Una consulta, todas las medidas aplicables, vinculadas a la fuente.
Las consultas conscientes de la fecha conservan las entradas que generaron el resultado.
- Introduzca lo que necesita una declaración de aduanas: el código CN/TARIC, el país de destino, la fecha relevante. Restricciones opcionales — tipo de medida, códigos adicionales.
- Reciba dos capas en un único informe: un aviso de anexo de sanciones cuando aplique, más el panorama completo de medidas TARIC — suspensiones arancelarias, controles de importación/exportación, prohibiciones, reglas específicas de origen — cada una con referencia al reglamento, rango de fechas y definiciones de condiciones integradas.
- Cada medida remite a su fuente — el reglamento de la UE subyacente o la entrada de la base de datos TARIC. El informe muestra a revisores (y auditores) el razonamiento, no solo el veredicto.
- Consultas conscientes de la fecha. Reproduzca un control para cualquier fecha anterior. Defienda una decisión pasada con el estado regulatorio exacto que aplicaba entonces.
- Los parámetros guardados viajan con los resultados. Las entradas que produjeron un control se conservan junto a la salida. Sin lagunas tipo «¿qué busqué?» en el rastro de auditoría.
- El mismo control, cada canal — web, API, MCP. Salida idéntica, fuentes idénticas.
Consciente de la fecha
Parámetros guardados
Idéntico vía API/MCP
07 · Cribado de sanciones
Diecisiete listas. Cada variante. Un resultado auditable.
Las fuentes oficiales de sanciones son navegables y están vinculadas al registro original.
- Qué se criba. Nombres — personas, empresas, buques, aeronaves — junto con alias, variantes locales de nombres, transliteraciones, fechas de nacimiento e identificadores (pasaporte, IMO, BIC, números de registro).
- Contra qué se criba. Diecisiete listas oficiales, mantenidas automáticamente (tabla al lado).
- La lógica de coincidencia detecta lo que la revisión manual omite. Alias, transliteraciones, equivalentes fonéticos y patrones de nombres locales se evalúan junto a las coincidencias exactas. El umbral es configurable por control.
- Cada coincidencia viene con su fuente. Cada coincidencia remite a la entrada original de la lista — nombre de la lista, programa, referencia al reglamento, motivos de inclusión. El revisor ve pruebas, no solo un veredicto.
- También sanciones a nivel de mercancía. El mismo flujo verifica códigos CN/TARIC frente a los anexos restrictivos de mercancías (p. ej. Reg. UE 833/2014 ANEXO XXIII), de modo que un control de entidad y un control de mercancía aterrizan en el mismo expediente.
- Navegue el conjunto de datos estructurado directamente. La Reference Library muestra la tabla de entidades listadas — filtre por programa, tipo, país o fuente cuando verifique un registro de fuente fuera de un cribado activo.
Cobertura de datos · 17 fuentes
| Fuente oficial | Autoridad |
|---|
| OFAC SDN | Estados Unidos |
| OFAC Non-SDN | Estados Unidos |
| EU FSF | Unión Europea |
| EU Russia (Reg. 833/2014) | Unión Europea |
| EU Belarus (Reg. 765/2006) | Unión Europea |
| EU Russia asset-freeze (Reg. 269/2014) | Unión Europea |
| UN SC Consolidated | Naciones Unidas |
| UK Sanctions List | Reino Unido |
| CH SECO | Suiza |
| JP MOF | Japón |
| AU DFAT | Australia |
| CA SEMA | Canadá |
| EE national sanctions | Estonia |
| LV FID | Letonia |
| LV FID frozen-assets | Letonia |
| PL MSWiA | Polonia |
| UA NSDC | Ucrania |
Listas mantenidas automáticamente. Sanciones a nivel de bienes verificadas simultáneamente contra anexos TARIC.
08 · Cribado de pagos ISO 20022
Cribado pre-flight para pain.001 y pacs.008.
Un wrapper consciente de mensajes alrededor del mismo motor. Carga útil cruda conservada como evidencia de auditoría.
- Full Payload Mandate. Todo el XML crudo pain.001 / pacs.008 se conserva como artefacto binario inmutable. Los campos prefiltrados están prohibidos — rompen la cadena de custodia.
- Validación XSD contra esquemas oficiales iso20022.org. Los fallos estructurales disparan un Integrity Error y mantienen el expediente en "Needs Review" hasta que un revisor registre justificación.
- Modelo de 6 nodos participantes. Sender Bank, Ordering Institution, Ordering Customer, Intermediary Banks, Beneficiary Bank, Beneficiary — cada uno cribado contra las mismas catorce fuentes. Detalle en la diapositiva siguiente.
- Cascada de resolución BIC a entidad. Tier 1 caché GLEIF local · Tier 2 API en tiempo real · Tier 3 búsqueda LLM con grounding — URL fuente capturada como evidencia inmutable.
- Unified Verdict + Persona Separation. Un solo hit de alto riesgo en cualquier nodo marca la transacción. Nodos persona obtienen lógica Persona; nodos entidad obtienen lógica Entidad.
- Conflict Detection. Si el nombre resuelto por BIC difiere del XML, el expediente levanta una Data Integrity Warning — defensa contra ofuscación de nombres.
Promesa de marca · case-as-audit
Lo difícil no es el cribado. Es defender el resultado.
Cada transición de estado lleva sello temporal y etiqueta de revisor. Las instantáneas históricas conservan el estado de las listas al momento del cribado — defensa ante argumentos futuros de "data drift".
Para empresas, bancos regionales, notarios — cualquiera cuya transferencia saliente los exponga a responsabilidad OFAC, UE o UK — el expediente es la auditoría.
09 · Modelo de 6 nodos participantes
Cada pain.001 se descompone en seis participantes cribables.
Cada nodo se criba independientemente. Un hit de alto riesgo en cualquiera marca la transacción.
| # | Rol | Mapeo pain.001 | Mapeo pacs.008 | Entidad | Qué se criba |
|---|
| 1 | Sender Bank | DbtrAgt (implied initiation) | InstgAgt | Entidad | Banco comercial originador. BIC resuelto contra las catorce fuentes para propiedad/sanciones jurisdiccionales. |
| 2 | Ordering Institution | DbtrAgt (Debtor Agent) | DbtrAgt (Debtor Agent) | Entidad | El Debtor Agent identificado en el XML. Frecuentemente el mismo que Sender Bank para pain.001 directo — no siempre. Cribado por separado. |
| 3 | Ordering Customer | Dbtr (Debtor) | Dbtr (Debtor) | Persona | La entidad legal originadora del pago. Lógica de Persona (DOB, pasaporte), coincidencia de nombre completo. |
| 4 | Intermediary Banks | N/A | IntrmyAgt1 → IntrmyAgt[n] | Entidad | Cadena de corresponsales. Frecuentemente invisible al originador pero materialmente expuesta si un corresponsal sancionado está en la ruta. |
| 5 | Beneficiary Bank | CdtrAgt (Creditor Agent) | CdtrAgt (Creditor Agent) | Entidad | La institución receptora. El objetivo de cribado más pasado por alto — atrapa exposición UE Rusia/Bielorrusia bajo Reg. 833/765. |
| 6 | Beneficiary | Cdtr (Creditor) | Cdtr (Creditor) | Persona | La parte receptora final — entidad legal o persona física. Lógica de Persona o Entidad según tipo. |
Por qué seis, no dos
La mayoría de herramientas del lado empresa verifican el Beneficiary (nodo 6) y se detienen. La exposición real está en los nodos 4 y 5 — corresponsales intermediarios y banco beneficiario. Un beneficiario limpio en un corresponsal sancionado no es una transacción defendible.
10 · Screening Cases — factor diferenciador
Cada control entra en un expediente. Cada expediente es su propia auditoría.
El artefacto de decisión, no solo la salida en bruto del cribado.
- La unidad de trabajo de cumplimiento es el expediente, no el control. Una transacción, cliente o envío genera muchos controles — pero el auditor ve una sola decisión. El expediente es el artefacto de esa decisión.
- Cada control se une a un expediente. Búsquedas TARIC, cribados de sanciones contra personas/empresas/buques/aeronaves, verificaciones bancarias y cribados de pagos ISO 20022 (mensajes pain.001 / pacs.008) — todos los hilos de una sola decisión viajan juntos.
- Los estados del ciclo de vida dirigen el flujo de trabajo. Abierto → Requiere revisión → Cerrado → Archivado. Cada transición se registra con marca de tiempo, revisor y estado de los datos en ese momento.
- Las coincidencias aparecen en el expediente. Marcadores rojos «coincidencia», entradas con vínculo a la fuente, notas del revisor — visibles en el contexto del expediente, no enterradas en una herramienta de alertas aparte.
- El factor diferenciador frente a Refinitiv, Dow Jones, Sayari: ellos le entregan resultados de cribado. Compliance Platform le entrega el expediente al que pertenecen esos resultados — el artefacto listo para auditoría, no la salida en bruto.
- Reproducible más tarde. Reabra cualquier expediente para ver los parámetros, coincidencias, fuentes y razonamiento del revisor exactos tal como estaban entonces. La auditoría no es una tarea aparte — el expediente es la auditoría.
ISO 20022
Cribado de pagos, listo para expediente. Pegue pain.001 / pacs.008 XML — la cadena (hasta 6 nodos) se criba frente a las catorce listas (véase diapositiva 9), pruebas junto al expediente.
La auditoría no es una tarea aparte — el expediente es la auditoría.
11 · AI Assistant + MCP
El mismo rastro de pruebas. Ahora accesible para un agente.
La capa de agentes está fundamentada, citada y registrada — no es un silo de IA paralelo.
- El AI Assistant es una interfaz de recuperación, no una herramienta de generación. Pregunte qué medidas TARIC aplican, qué listas contienen un nombre, qué expedientes involucraron a una contraparte — el asistente consulta datos indexados y devuelve resultados citados.
- MCP expone los mismos flujos de trabajo a agentes externos. Cualquier cliente compatible con MCP — Claude, ChatGPT Agents, personalizado — puede invocar el cribado como herramienta nativa y recibir pruebas con vínculo a la fuente.
- Ambas interfaces están fundamentadas. Sin reglamentos alucinados, sin programas de sanciones inventados, sin citas plausibles pero falsas. El agente devuelve lo que la plataforma indexa — nada más.
- Los controles dirigidos por agentes aterrizan en el mismo registro Screening Cases. Web, API, MCP — el mismo expediente, el mismo rastro de auditoría. No hay «silo de IA» en el que los controles escapen a la auditoría.
- Uso práctico: redactar notas del revisor para coincidencias ambiguas, recuperar expedientes pasados relacionados con un país o programa, verificar por lotes listas de contrapartes / buques / bancos, resumir condiciones de reglamentos en lenguaje claro.
- Los compradores de cumplimiento en 2026 son legítimamente escépticos ante la IA. La capa de agentes de la plataforma se gana la confianza porque está fundamentada, citada y registrada — no afirmando «confíe en nosotros, nuestra IA es distinta».
Inteligencia agéntica
AI Assistant
Recuperación en la consola
MCP Server
Agentes externos
Datos indexados
Sin alucinaciones
Screening Cases
El mismo expediente · la misma auditoría
La confianza en la IA se gana con citas y registro de auditoría — no con una vaga promesa «impulsada por IA».
12 · Estado y llamada a la acción
Pre-lanzamiento. Acceso de prueba abierto desde hoy.
Una alianza de retroalimentación para equipos que necesitan cribado defendible sin la sobrecarga corporativa.
- Etapa. Lanzamiento de la plataforma de producción previsto para el verano de 2026.
- Acceso de prueba disponible desde hoy. Sin mínimo de seis cifras, sin integración de seis meses, sin exigir un departamento de cumplimiento. Disponible para equipos de cualquier tamaño.
- Qué incluye el acceso de prueba. Web UI completa, API y MCP Server; listas de sanciones actuales; medidas TARIC vigentes; Screening Cases y rastro de auditoría.
- Qué pedimos a cambio. Preguntas reales sobre flujos de trabajo, comentarios sobre lagunas de cobertura, casos de uso de integración. Sin compromiso de cliente pagador.
- Transparencia defensiva. Sin relación con la Comisión Europea. No sustituye las fuentes oficiales ni las decisiones de las autoridades competentes.
- Contacto. Escriba a sales@norvext.com
Contacto
sales@norvext.com
Comparta el caso de uso concreto y el volumen esperado — adaptamos el acceso piloto a controles comerciales y regulatorios, revisión de sanciones, preparación de pruebas o integración API/MCP.
Apéndice A · Listas de sanciones admitidas
Diecisiete fuentes oficiales. Una superficie de cribado consolidada.
Cada lista a continuación es una fuente oficial gubernamental o supranacional, sincronizada automáticamente y vinculada al registro original — cribadas juntas en una única ejecución.
| Fuente oficial |
Autoridad |
Jurisdicción |
| UN SC Consolidated List | UN SC | Naciones Unidas |
| EU Consolidated Financial Sanctions (FSF) | Comisión Europea / DG FISMA | Unión Europea |
| EU Russia asset-freeze — Reg. 269/2014 | EUR-Lex | Unión Europea |
| EU Russia — Reg. 833/2014 | EUR-Lex | Unión Europea |
| EU Belarus — Reg. 765/2006 | EUR-Lex | Unión Europea |
| OFAC SDN List | U.S. Treasury / OFAC | Estados Unidos |
| OFAC Consolidated Non-SDN List | U.S. Treasury / OFAC | Estados Unidos |
| UK Sanctions List | UK FCDO | Reino Unido |
| Swiss SECO Sanctions List | SECO | Suiza |
| Canada Consolidated (SEMA) | Global Affairs Canada | Canadá |
| Australian Sanctions Consolidated List | DFAT | Australia |
| Japan MOF economic sanctions | Ministerio de Finanzas de Japón | Japón |
| Ukraine State Register of Sanctions | NSDC de Ucrania | Ucrania |
| Estonian Government national sanctions | Ministerio de Asuntos Exteriores de Estonia | Estonia |
| Latvia FID National Sanctions List | FID de Letonia | Letonia |
| Latvian FID frozen-assets registry | FID de Letonia | Letonia |
| Poland MSWiA national sanctions list | MSWiA de Polonia | Polonia |
Cobertura de un vistazo
5 multilaterales / de toda la UE — Consejo de Seguridad de la ONU, EU FSF y los tres reglamentos EUR-Lex sobre Rusia/Bielorrusia (269/2014, 833/2014, 765/2006).
8 nacionales — Estados Unidos (OFAC SDN + Non-SDN), Reino Unido, Suiza, Canadá, Australia, Japón, Ucrania.
4 de Estados miembros de la UE — Estonia, Letonia (lista FID + registro de activos congelados), Polonia.
Cómo se mantienen actualizadas las fuentes
La mayoría de las fuentes se sincronizan a diario; las listas impulsadas por publicación se actualizan en cada actualización oficial. Cada coincidencia de cribado cita su lista de origen, programa y referencia legal — véase el Apéndice B para los algoritmos de coincidencia.
Apéndice B · Algoritmos de búsqueda close-match
Seis rutas de búsqueda en paralelo. Gana la señal más fuerte.
Los nombres rara vez coinciden exactamente. Trigram, token-sort, fonético, edit-distance, exact-token e identificador evalúan la misma consulta — la puntuación refleja la ruta más fuerte.
| # | Algoritmo | Tecnología | Qué captura |
|---|
| 1 | Similitud trigram | pg_trgm · GIN | Superposición de fragmentos de tres letras. Ivanov Ivan ↔ Ivanov Ivan Petrovich. |
| 2 | Trigram token-sort | pg_trgm · tokens ordenados | Elimina efectos de orden de palabras. Sirius Trading ↔ Trading House Sirius. |
| 3 | Double Metaphone | fuzzystrmatch | Equivalencia fonética. Ivanov ↔ Ivanoff, Mikhail ↔ Michael. Cirílico se translitera primero. |
| 4 | Levenshtein | levenshtein_less_equal() | Conteo mín-edit para cadenas cortas y errores de tipeo. Ivanov ↔ Ivanoff. |
| 5 | Exact token | tabla de tokens · btree | Lookup determinístico por aliases/transliteraciones. Northbridge Trading Ltd ↔ alias almacenado. |
| 6 | Match de identificador | identificadores normalizados | Registro, IMO, BIC/SWIFT, pasaporte, ID nacional, ID fiscal. Fuerza puntuación a 100. |
Modelo de puntuación
raw = max(señal) × 100 sobre las seis rutas anteriores.
+ bonus: DOB coincide +10, país coincide +5.
− safety caps: consulta fuzzy-only de un solo token se limita a 84 (tier review) — "Ivanov" solo nunca confirma identidad.
↑ override: match de identificador exacto fuerza 100.
Tiers de puntuación · umbral por defecto 75
100 Evidencia confirmada · 90–99 Hit (revisión manual obligatoria) · 75–89 Review (investigar antes de cerrar) · <75 Débil (no se devuelve al umbral por defecto)
Apéndice C · VoP — Verification of Payee
Clasificación close-match EPC288-23 sobre el cribado estándar.
Bajo Reg. (UE) 2024/886, el originador debe verificar el nombre del beneficiario — no solo su banco. Nuestro wrapper VoP toma los mismos candidatos sanciones del Apéndice B y clasifica la coincidencia de nombre según reglas EPC288-23.
| Resultado | Escenario | Lógica | Ejemplo |
|---|
| MTCH | exact | igual tras normalización | Jan Kowalski = Jan Kowalski |
| CMTC | s2a_levenshtein | edit-distance ≤ 2 | Muller ~ Mueller |
| CMTC | s2b_transposition | un intercambio adyacente | Smtih ~ Smith |
| CMTC | s2c_initial | inicial + apellido | J Smith ~ John Smith · solo persona física |
| CMTC | s2d_phonetic | equivalencia fonética | Kowalsky ~ Kowalski · solo persona física |
| NMTC | no_match | ningún escenario activado | ABC Trading vs XYZ Logistics |
| NOAP | not applicable | nombre registrado no disponible | el PSP del beneficiario no devolvió nombre |
VoP clásico vs nuestro VoP
VoP clásico pregunta "¿el nombre del beneficiario coincide con el titular de la cuenta IBAN?" — respondido por el PSP del beneficiario.
Nuestro VoP pregunta "¿el nombre del beneficiario coincide con un candidato sanciones?" — wrapper sobre el cribado estándar del Apéndice B con clasificación close-match EPC288-23.
Normalización VoP · 6 pasos
1. Minúsculas · 2. Expansión nórdica (ø→oe, ä→ae, ß→ss) · 3. Unaccent (é→e) · 4. Eliminar sufijos legales (SIA, LLC, GmbH) · 5. Whitelist [a-z0-9\s] · 6. Comprimir espacios
