Objetivo: Diseñar un Control Plane y Tenant Factory que permita operar como SaaS multi‑tenant desde el día uno, con opciones de entornos dedicados y nodos privados (edge) para clientes sensibles.

ADRs relevantes

• ADR‑004 (Tenancy & Deployment) — Multi‑tenant por defecto; soporte para entornos dedicados y despliegues privados. Aislamiento lógico obligatorio.
• ADR‑005 (Tenant Federation) — Soporte para relaciones parent/child con políticas compartidas opcionales.
• ADR‑001 (Regulator Evidence Gateway) — Acceso regulador por evidencia y casos, no por acceso total.

Tareas (Mínimo viable)

• Definir modelo de tenancy: tenant_id, tenant_metadata, tenant_keys (no inventar nombres de columnas en código aún).
• Implementar Tenant Factory API: crear/activar/desactivar/clone tenant (idempotente).
• Diseñar y desplegar IAM con SSO (SAML/SCIM/OIDC) + RBAC + ABAC extensible.
• Implementar KMS por tenant (segregación de claves) y vaulting de secretos.
• Políticas de red y opcional VPC peering para tenants dedicados; plantilla IaC (Terraform/CloudFormation).
• Auditoría de aprovisionamiento: every API call → immutable audit event.

Riesgos principales

Mitigantes

Criterios de aceptación (MVP)

• API de creación de tenant devuelve tenant_id y material criptográfico; operación idempotente.
• SSO (OIDC/SAML) configurado y probado con 1 proveedor (Google Workspace) y SAML partner demo.
• Registros de auditoría inmutables (append-only) para operaciones de tenant provisioning.
• Pruebas de aislamiento (penetration tests básicos) sin fuga entre 2 tenants.

Agentes & Sub‑agentes (Estructura)

Stack tecnológico recomendado

Epics & Historias (ejemplos)

Objetivo: Implementar flujos de captura de identidad, verificación documental y KYB con trazabilidad del beneficiario final desde fase inicial (MVP) con Human‑in‑the‑loop (HiTL).

ADRs relevantes

• ADR‑006 — Soporte para personas físicas y morales (UBO) desde Phase 1.
• ADR‑003 — La IA asiste; la decisión legal final es del Oficial de Cumplimiento.

Tareas clave

• Diseñar expediente electrónico (case file) con evidencias versionadas.
• Integrar proveedores de validación documental (Jumio/Onfido o alternativas locales).
• OCR y extracción estructurada (ID, RFC, CURP, datos fiscales).
• Implementar flujo de KYB: registro de sociedad, constitución, RFC, actos inscritos.
• Motor de inferencia UBO: relaciones societarias + graph builder para ownership chains.
• Módulo HiTL: cola de revisión manual, SLA de revisión, anotaciones forenses.

Riesgos principales

Mitigantes

Criterios de aceptación (MVP)

• Flujo KYC individual end‑to‑end: capture → doc verify → selfie/liveness → status (verified/manual).
• KYB mínimo: registrar entidad, cargar constitución y RFC, primer nivel de UBO detectado y graph inicial.
• Expediente con evidencia PDF generado y firmado digitalmente (hash) listo para auditoría.

Agentes & Sub‑agentes

Stack tecnológico recomendado

Epics & Historias (ejemplos)

Objetivo: Proveer capacidades de screening robustas, explicables y actualizables, con reglas de descarte y flujo HiTL para evitar decisiones automáticas no auditadas.

ADRs relevantes

• ADR‑001 — Regulador accede solo a evidencias y casos.
• ADR‑003 — AI asistente; decisión final humana.

Tareas mínimas

• Integrar feeds: OFAC, UN, EU, local (UIF Mexico) y listas comerciales (World‑Check/ComplyAdvantage).
• Implementar motor de matching con soporte fuzzy, fonético y transposition matching (apellidos compuestos, tildes).
• Implementar reglas de descarte/aceptación (usar plantilla de reglas descarte screening.xlsx como fuente).
• Registrar evidencia: snapshot de la lista + parámetros de matching (algoritmo, umbral).
• Adverse Media: ejecutar búsquedas de noticias (adverse media) y enlazar evidencias al perfil.

Riesgos principales

Mitigantes

Criterios de aceptación (MVP)

• Ingest de al menos 3 feeds sancionatorios y programación automática de refresh (daily/real‑time según feed).
• Motor de matching que exponga: matched_fields, match_score, algorithm_used y snapshot de la fuente.
• Implementación inicial de reglas de descarte (basado en archivo “reglas descarte screening.xlsx”).

Agentes & Sub‑agentes

Stack tecnológico recomendado

Epics & Historias (ejemplos)

Objetivo: Construir pipeline de ingest de transacciones, normalización, reglas + ML, mapeo a tipologías (Typology Engine) y generación de alertas / casos con trazabilidad para SAR/STR.

Tareas críticas

• Catalogar adaptadores de entrada: SPEI, tarjetas, transferencias bancarias, pasarelas de pago, cripto (exploratorio).
• Normalización de eventos financieros (canonical schema) y enriquecimiento (KYC link, geolocation, device fingerprint).
• Motor de reglas tradicional + ML scoring (anomalies) y mapeo a tipologías (Dom.5 later integra inferencia).
• Implementar backpressure y circuit‑breakers en adaptadores de alta tasa.
• Sistema de alertas → Case Manager (expediente) y feedback loop (analyst verdict → tune rules/models).

Riesgos principales

Mitigantes

Criterios de aceptación (MVP)

• Conector funcional a al menos 1 origen (ej. SPEI feed o archivo CSV de transacciones) y pipeline end‑to‑end.
• Reglas configurables por UI que generen alertas, con link directo al expediente del cliente (KYC).
• Capacidad de procesar un throughput de referencia (por ejemplo, 100 tx/s para mercado inicial) con degradación controlada.

Agentes & Sub‑agentes

Stack tecnológico recomendado

Epics & Historias (ejemplos)

Objetivo: Ingestar, normalizar y operacionalizar las tipologías (archivos CSV: tipologias matriz operativa.csv, tipologias globales.csv) en una Knowledge Base versionada que el motor de inferencia use para mapear alertas/transacciones a tipologías con estrategias de razonamiento (abducción, inducción, analogía, etc.).

ADRs relevantes

• ADR‑006 — Tipologías desde Sprint 0; mapping de señales (señal_de_alerta_clave) → reglas detectables.
• ADR‑003 — Resultado de inferencia asistido, verificado por humano para decisión final.
• ADR‑001 — Cada tipología referenciará fuentes (FATF/GAFILAT/UIF) y deberá citar origen en reportes.

Tareas (MVP → iteraciones)

• Ingestar los CSV proporcionados; crear pipeline ETL que normalice columnas y detecte campos clave (tipologia, señal_de_alerta_clave, fase_lavado, delito_precedente, herramienta_deteccion).
• Diseñar esquema de Knowledge Base: nodes (tipología, señal, sector, producto, fuente) + relations; persistir en Graph DB.
• Construir index RAG: embeddings de descripciones/nota → vector DB y documentos referenciales (PDF/URL).
• Implementar motor de inferencia con módulos: Abduction, Induction, Analogy, Probabilistic Ranking, Typicality Heuristics.
• Mapear cada regla/red flag a una regla técnica detectable (ej.: “margen reventa >200%” → rule: unit_price_ratio > 2.0 con soporte documental).
• Crear Typology Curator UI para editar, versionar y aprobar nuevos patrones (workflow de cambio con PR + audit trail).

Riesgos principales

Mitigantes

Criterios de aceptación (MVP)

Agentes & Sub‑agentes (Estructura)

Stack tecnológico recomendado

Epics & Historias (ejemplos)

Objetivo: Definir y operar un motor de scoring que combine factores estáticos (perfil, sector, jurisdicción) y dinámicos (comportamiento transaccional, typology matches, screening hits) para producir un Risk Score auditable y un EWRA con triggers operativos.

ADRs relevantes

• ADR‑002 — Priorizar segmentos objetivo y calificar riesgos por cliente/entidad.
• ADR‑001 — Todos los scores deben ser explicables y auditablemente referenciables.

Tareas principales

• Definir taxonomía de factores de riesgo (jurisdicción, producto, sector, UBO risk, sanctions hits, typology matches, anomaly score).
• Implementar pipeline de features en Feature Store (latency, rolling windows, aggregates).
• Desarrollar Risk Scorer: reglas determinísticas (policy layer) + ML model (calibrado) para score continuo.
• Diseñar EWRA: umbrales, escalation matrix, SLA de respuesta, notificaciones automatizadas.
• Incluir explainability: per‑score SHAP/feature importances + human readable justification templates.

Riesgos principales

Mitigantes

Criterios de aceptación (MVP)

Agentes & Sub‑agentes

Stack tecnológico recomendado

Epics & Historias (ejemplos)

Objetivo: Generar borradores estructurados de reportes regulatorios (SAR/STR/ROS/CTR) y paquetes de evidencia que respeten jurisdicciones y cumplan requisitos mínimos formales; la generación asistida por AI debe incluir RAG con citas y pruebas, y siempre estar sujeta a aprobación humana.

ADRs relevantes

• ADR‑001 — Evidencia y trazabilidad para reguladores; no exponer datos fuera del alcance del caso.
• ADR‑003 — IA sugiere lenguaje, el Oficial de Cumplimiento aprueba y firma.
• ADR‑007 — GTM y posición comercial para mensajes de producto vs servicio.

Tareas críticas

• Definir templates legales por jurisdicción (CNBV/UIF, FinCEN, EU formats) y metadatos obligatorios.
• Implementar RAG‑driven narrative generator que cite fuentes (tipologías, feeds, transacciones) y adjunte evidencia (PDF hashes, screenshots).
• Generar paquete listo para envío: PDF firmado, metadatos machine‑readable (JSON) y log de aprobaciones.
• Registrar envíos y respuestas regulatorias en el expediente (evidence pack) con timestamps y hash.
• Integrar firma digital / e‑sign (Docuseal / DocuSign) y preparar export para portales regulatorios (CSV, XML según necesidad).

Riesgos principales

Mitigantes

Criterios de aceptación (MVP)

Agentes & Sub‑agentes

Stack tecnológico recomendado

Epics & Historias (ejemplos)

Objetivo: Definir el Master Orchestrator (control plane) que registre, enrute y supervise sub‑agentes especializados (Onboarding, Screening, Typology, Risk, Reporting, TMS). Debe ofrecer contratos de comunicación, políticas de retry/timeout, y observabilidad consolidada.

ADRs relevantes

• ADR‑004 — Control plane must support multi‑tenancy and isolated tenant policies.
• ADR‑001 — Supervisory Evidence Gateway lives behind orchestrator policies for regulator access.

Tareas esenciales

• Diseñar Agent Registry: catálogo de agentes, versiones y capabilities (capabilities = what inputs/outputs they accept).
• Definir standard event schema / contract (trace_id, tenant_id, case_id, timestamp, payload_type).
• Implementar broker/event bus (Kafka) con topics por dominio y control de tenancy (partitioning).
• Política de orquestación declarativa (Temporal / Cadence / Argo Workflows) para flows complejos y retries con circuit breakers.
• Implementar control plane APIs: register_agent, invoke_agent, get_status, cancel_workflow, scale_agent.
• Observabilidad: tracing (Jaeger), metrics (Prometheus), logs centralizados (ELK/Opensearch).

Riesgos principales

Mitigantes

Criterios de aceptación (MVP)

Agentes & Estructura (Control Plane)

Stack tecnológico recomendado

Epics & Historias (ejemplos)

Objetivo: Proporcionar capacitación continua e inteligente para el staff de cumplimiento de los clientes (Oficiales, Analistas, Soporte), con cursos sobre PLD/FT, tipologías, herramientas, y auditoría interna. Debe incluir tracks personalizados por rol, progreso medible y certificación digital.

ADRs relevantes

• ADR‑002 — Segmento inicial: profesionales y pequeñas instituciones con necesidad de educación básica.
• ADR‑003 — Certificación de conocimiento es un paso previo a tomar decisiones legales.

Tareas mínimas

• Definir tracks de aprendizaje: Introductorio, Avanzado, Especialista (por temas: Crypto, TBML, Tipologías).
• Integrar contenido multimedia: videos, cuestionarios autoevaluables y pruebas de certificación.
• Diseñar gamification ligera: badges, streaks, leaderboard opcional y avance track por tenant.
• Implementar LMS UI responsive con SSO integrado (tenant-aware) y soporte offline básico.
• Emitir certificados con hash firmado digitalmente y persistir en expediente del usuario.
• Integración con Typology KB: cursos de actualización automática cuando se publica una nueva tipología.

Riesgos principales

Mitigantes

Criterios de aceptación (MVP)

Agentes & Sub‑agentes

Stack tecnológico recomendado

Epics & Historias (ejemplos)

Objetivo: Implementar sistema de logging seguro, inmutable y consultable para todas las operaciones relacionadas con clientes, transacciones, screening, tipologías, decisiones humanas y accesos regulatorios. Debe cumplir con estándares de auditoría como SOC 2 y GDPR.

ADRs relevantes

• ADR‑001 — Toda acción debe poder ser auditada; logs son append‑only y criptográficamente seguros.

Tareas esenciales

• Diseñar formato estandarizado de log: tenant_id, case_id, trace_id, timestamp, actor (human/system), action, resource_type, resource_id, metadata (payload_hash).
• Implementar append-only log store (ej. Chronicle / TimescaleDB hypertables / append-only Kafka topics).
• Integrar firma criptográfica (hash chaining) o Merkle trees para integridad de logs.
• Exportación programada de logs para backup y auditoría externa (CSV + JSON + firmado).
• Query engine eficiente para auditorías (ej. logs desde “transacción X” hasta “decisión final Y”).
• Retention policy: configurable por tenant, con cumplimiento de 7–10 años según jurisdicción.

Riesgos principales

Mitigantes

Criterios de aceptación (MVP)

Agentes & Sub‑agentes

Stack tecnológico recomendado

Epics & Historias (ejemplos)

Objetivo: Diseñar pipelines de ingest automatizados para fuentes externas (tipologías, sanciones, noticias, jurisprudencia, reglamentos) y un sistema de gestión de cambios de datos/versiones con aprobación humana.

ADRs relevantes

• ADR‑001 — Toda fuente externa debe tener versionado, hash y trazabilidad para auditorías.
• ADR‑006 — Tipologías deben ser curadas y aprobadas antes de publicarse al motor de inferencia.

Tareas críticas

• Detectar y conectar fuentes: RSS de UIF México, FATF, GAFILAT, BOE España, SAT, DOF.
• Diseñar adaptadores modulares: PDF scraper, RSS parser, API connector, web crawler (si necesario).
• Incorporar mecanismo de diff: comparar nueva versión vs anterior para detectar cambios relevantes.
• Workflow de aprobación: propuesta → diff → human review → publish → notify stakeholders.
• Integración con Typology KB (Dominio 5): nueva tipología → notificación a LMS y Orchestrator.
• Notificación automática a usuarios cuando se publican cambios importantes (newsletter + in‑app).

Riesgos principales

Mitigantes

Criterios de aceptación (MVP)

Agentes & Sub‑agentes

Stack tecnológico recomendado

Epics & Historias (ejemplos)

Objetivo: Garantizar trazabilidad completa de datos (desde fuente hasta consumidor), políticas de calidad, retención y privacidad, así como linaje de modelos ML (versión, datos de entrenamiento, métricas, bias checks).

ADRs relevantes

• ADR‑001 — Todo dato debe tener linaje (data lineage), política de retención, y cumplir con protección de datos.

Tareas clave

• Definir data catalog: datasets, schemas, owners, lineage (origen → transformación → destino).
• Implementar data quality checks (ej. completeness, uniqueness, referential integrity).
• Aplicar data minimization: solo persistir lo necesario, con políticas de purga automática.
• Model lineage: registrar modelo, dataset usado, fecha de entrenamiento, métricas, bias checks.
• Integrar con IAM: quien puede leer/modificar qué datos, bajo qué condiciones.
• Exposición de dashboards: calidad de datos, linaje, modelos en producción, drift reports.

Riesgos principales

Mitigantes

Criterios de aceptación (MVP)

Agentes & Sub‑agentes

Stack tecnológico recomendado

Epics & Historias (ejemplos)

Objetivo: Proveer un motor de workflows declarativos y reproducibles que permita modelar procesos de cumplimiento (ej.: Onboard → Screen → Score → Escalar → SAR Draft) como código, con versionado, testing y posibilidad de ejecución híbrida (sync/async).

ADRs relevantes

• ADR‑004 — El control plane debe soportar flujos declarativos y multi‑tenant.
• ADR‑003 — Automatizaciones no deben reemplazar la decisión humana para decisiones legales.
• ADR‑001 — Todo flujo debe producir evidencia rastreable y auditable.

Tareas principales

• Definir DSL (Workflows as Code) o adoptar Temporal/Argo/State Machine con definiciones YAML/JSON versionadas.
• Implementar librería de task primitives reutilizables (invoke_agent, call_api, wait_for_manual_approval, attach_evidence, sign_document).
• Construir interfaz visual de authoring (drag & drop) + editor de código, con validación y testing integrado.
• Integrar gates HiTL: manual approval steps, SLA timers, escalation policies.
• Implementar testing: unit tests para tasks, integration tests que simulen eventos y validen side effects (logs, DB writes).
• Versionado y rollback de workflows; canary execution y feature flags para experimentación.

Riesgos principales

Mitigantes

Criterios de aceptación (MVP)

Agentes & Sub‑agentes

Stack tecnológico recomendado

Epics & Historias (ejemplos)

Objetivo: Definir la arquitectura cloud‑native, IaC, prácticas SRE, seguridad (zero‑trust), backup/DR y procedimientos operativos para garantizar disponibilidad, confidencialidad e integridad de un CaaS regulatorio.

ADRs relevantes

• ADR‑004 — Multi‑tenant infra desde el inicio; plantillas IaC para despliegues dedicados.
• ADR‑001 — Guardar evidencias con trazabilidad y protección criptográfica.

Tareas principales

• Definir Landing Zone / Account structure (org) en el proveedor cloud elegido (o multi‑cloud blueprint).
• Implementar IaC templates (Terraform modules) para: control plane, tenant stacks, networking (VPCs), kms, monitoring.
• Configurar CI/CD (ArgoCD / GitHub Actions) con pipelines para infra + app; despliegues canary y rollbacks automáticos.
• Implementar SRE playbooks: runbooks, playbooks incident response, SLO/SLA y error budgets.
• Seguridad: Zero‑Trust network policies, WAF, secrets management, vulnerability scanning (SCA), pentests regulares.
• Continuidad: Backup strategy, cross‑region DR, RTO/RPO targets y pruebas regulares de DR.

Riesgos principales

Mitigantes

Criterios de aceptación (MVP)

Agentes & Roles operativos

Stack tecnológico recomendado

Epics & Historias (ejemplos)

Objetivo: Proveer a reguladores acceso controlado, limitado y auditable a evidencia relevante de casos (expedientes) sin otorgar acceso general a la plataforma. El Gateway implementa time‑boxed, scope‑restricted, read‑only sessions, con capacidad de export firmado y control de escopo por caso/periodo.

ADRs relevantes

• ADR‑001 (Regulator Evidence Gateway) — Regulador accede a evidencia, no al sistema completo; sesiones deben ser auditable y revocables.
• ADR‑005 — Tenancy federation: support for parent/child tenants with scoped evidence sharing.

Tareas críticas

• Diseñar authorization model: roles for regulator actors, token scopes (case_read, evidence_download, metadata_only), and time limits.
• Implementar UI/portal read‑only para reguladores con session recording (video/keystroke optional) and read receipts.
• Implement API: request_evidence_access (case_id, justification, duration) → create scoped session token, notify tenant owner.
• Redaction & Minimization: ability to redact PII fields on a per‑request basis, with tenant approval flows if required by policy.
• Export signing: evidence pack exports digitally signed (hash+signature), produce JSON metadata + PDF bundle.
• Audit trail: every regulator access event written to immutable audit log with actor, justification, TTL and items accessed.
• Legal hold & embargo: ability for tenant to set holds and for gateway to respect legal embargoes while documenting regulatory requests.

Riesgos principales

Mitigantes

Criterios de aceptación (MVP)

Agentes & Sub‑agentes

Stack tecnológico recomendado

Epics & Historias (ejemplos)

Objetivo: Proporcionar herramientas para investigar y gestionar casos de sanciones complejas; incluye seguimiento de flujo de fondos, construcción de redes de propiedad/relaciones, y generación de reportes forenses para autoridades o litigios.

ADRs relevantes

• ADR‑001 — Toda investigación debe ser reproducible, con evidencia firmada y trazabilidad completa.
• ADR‑003 — IA asistente, pero Oficial firma decisiones.

Tareas principales

• Implementar Graph Explorer UI: visualizar nodos (personas, cuentas, empresas) y relaciones (transferencias, ownership, PEP links).
• Módulo de tracing: reconstrucción de cadena de transacciones, con capacidad de expandir conexiones (expand graph).
• Forensic annotation: permitir que Oficiales anoten evidencias visuales (notes, highlights, timestamps).
• Reporte forense: exportable PDF firmado con anotaciones + chain of custody.
• Integración con TMS y Screening para enlazar alertas con casos investigados.

Riesgos principales

Mitigantes

Criterios de aceptación (MVP)

Agentes & Sub‑agentes

Stack tecnológico recomendado

Epics & Historias (ejemplos)

Objetivo: Correlacionar señales entre Screening Hits, Transacciones Anómalas y Tipologías para detectar patrones multifacéticos de riesgo (ej.: transacciones altas + match en lista PEP + tipología TBML).

ADRs relevantes

• ADR‑001 — Correlaciones deben ser explicables y rastreables.
• ADR‑006 — Tipologías guían la interpretación de correlaciones.

Tareas principales

• Construir Event Correlator: recibe eventos de Screening, Transacciones y Tipologías y busca coincidencias.
• Definir scoring de correlación: combinar confidences de cada señal (ej. screening_confidence × anomaly_score × typology_match).
• Generar alertas fusionadas: casos que involucran múltiples fuentes de evidencia.
• Exponer UI con timeline de eventos correlacionados y sugerencias de tipología aplicable.

Riesgos principales

Mitigantes

Criterios de aceptación (MVP)

Agentes & Sub‑agentes

Stack tecnológico recomendado

Epics & Historias (ejemplos)

Objetivo: Integrar servicios legales en la plataforma: generación automática de contratos, términos de uso, avisos de privacidad, cláusulas de responsabilidad y SLAs. Debe cumplir con normativa mercantil local y reglamentaciones de proteccción de datos.

ADRs relevantes

• ADR‑007 — GTM usa mensajes cuidadosos de responsabilidad legal.
• ADR‑002 — Los documentos deben ser adaptables por jurisdicción.

Tareas principales

• Diseñar templates de contratos: Términos de Servicio, Privacidad, SLA, Responsabilidad Limitada, Política de Retención de Datos.
• Integrar firma electrónica: DocuSign / Docuseal / Adobe Sign con autenticación multifactor.
• Habilitar versionado de documentos con firmas y timestamps criptográficos.
• Adaptación jurisdiccional automática (MX, US, EU) basada en tenant settings.
• Generador de aviso de privacidad dinámico con consent checkboxes y logs.

Riesgos principales

Mitigantes

Criterios de aceptación (MVP)

Agentes & Sub‑agentes

Stack tecnológico recomendado

Epics & Historias (ejemplos)

Backlog Maestro de Sprints (0–6)

• Sprint 0: Discovery, Blueprint, Data Governance, Ingesta de Tipologías (CSV → KB)
• Sprint 1: Infra Cloud, Data Lake/Pipeline, IAM, Logging/Auditoría
• Sprint 2: AI Orchestration (Master + Specialized Agents), RAG, Routing
• Sprint 3: Aplicaciones Core (Onboarding, Screening, Monitoring, Risk Matrices)
• Sprint 4: Reporting Engine, Feed Aggregator, Correlación Cross-Función
• Sprint 5: LMS, Calendar/Video, Query Hub, Integraciones de Terceros
• Sprint 6: Endurecimiento, Testing de Cumplimiento, CI/CD, Observabilidad

{
  "tipologia_id": "tbml_001",
  "tipologia": "TBML + manipulación de precios agrícolas + empresas fachada",
  "ambito": "México / LATAM",
  "tipo_registro": "caso_analizado",
  "fase_lavado": "Colocación → Integración (ciclo corto)",
  "delito_precedente": "Narcotráfico / extorsión",
  "sector_vulnerable": "Agroindustrial",
  "producto_financiero": "Efectivo / SPEI",
  "señal_de_alerta_clave": "Margen reventa >200%",
  "norma_aplicable": "Art. 400 Bis CPF",
  "herramienta_deteccion": "Feedzai / ComplyAdvantage"
}

{
  "event_id": "ev_9f8e7d6c5b",
  "timestamp": "2025-04-05T14:30:22Z",
  "tenant_id": "tn_abc123",
  "actor": {
    "type": "human",
    "id": "usr_xyz987"
  },
  "action": "create_case",
  "resource_type": "case",
  "resource_id": "case_456def",
  "metadata": {
    "payload_hash": "sha3:abcd1234...",
    "case_type": "screening_hit"
  }
}

{
  "matched_typology": {
    "tipologia_id": "tbml_001",
    "confidence": 0.87,
    "inferred_phase": "layering",
    "strategy_used": "abduction",
    "cited_sources": [
      {
        "titulo": "Estudio de Tipologías en Materia de Lavado de Activos Basado en el Comercio",
        "organizacion": "OAS / GELAVEX",
        "anio": 2019
      }
    ],
    "matched_signals": [
      {
        "signal": "margen reventa >200%",
        "detected_in": "transaction_monitoring"
      }
    ]
  }
}

{
  "inputs": {
    "signals": [
      {
        "signal": "cliente nuevo con depósito > $100k",
        "source": "transaction_monitoring"
      },
      {
        "signal": "match PEP con score > 0.95",
        "source": "screening_engine"
      }
    ],
    "strategy": "abduction"
  },
  "output": {
    "hypotheses": [
      {
        "description": "Cliente nuevo oculta origen de fondos usando PEP como pantalla.",
        "confidence": 0.91,
        "typology_match": "smurfing + PEP"
      }
    ]
  }
}

{
  "score_id": "sc_123abc",
  "client_id": "cli_def456",
  "value": 0.78,
  "category": "High Risk",
  "drivers": [
    {
      "factor": "PEP Match",
      "weight": 0.3,
      "impact": "increase"
    },
    {
      "factor": "Transacción Anómala",
      "weight": 0.25,
      "impact": "increase"
    }
  ],
  "generated_at": "2025-04-05T15:12:00Z"
}

{
  "sar_id": "sar_ghi789",
  "case_id": "case_456def",
  "client_info": {
    "name": "Juan Pérez",
    "rfc": "PEPJ800101XXX"
  },
  "narrative": "Cliente presenta transacciones >$100k sin perfil declarado. Match en lista PEP confirmado con score 0.95.",
  "matched_typologies": [
    {
      "tipologia": "smurfing + PEP",
      "confidence": 0.91
    }
  ],
  "evidences_attached": [
    {
      "type": "transaction_log",
      "hash": "sha3:def456..."
    },
    {
      "type": "screening_match_report",
      "hash": "sha3:ghi789..."
    }
  ]
}

{
  "fusion_case_id": "fc_987zyx",
  "correlated_events": [
    {
      "event_type": "screening_hit",
      "event_id": "sh_111aaa",
      "timestamp": "2025-04-05T10:00:00Z"
    },
    {
      "event_type": "transaction_anomaly",
      "event_id": "ta_222bbb",
      "timestamp": "2025-04-05T10:05:00Z"
    }
  ],
  "correlation_score": 0.93,
  "suggested_typology": "smurfing + PEP",
  "confidence": 0.89
}

{
  "feedback_id": "fb_333ccc",
  "fusion_case_id": "fc_987zyx",
  "analyst": "usr_xyz987",
  "feedback_type": "invalidate_correlation",
  "reason": "Coincidencia temporal falsa",
  "timestamp": "2025-04-05T16:45:00Z"
}

{
  "tenant_id": "tn_abc123",
  "settings": {
    "jurisdiction": "MX",
    "features_enabled": [
      "onboarding",
      "monitoring",
      "reporting"
    ],
    "policies": {
      "retention_days": 3650,
      "pii_minimization": true
    }
  },
  "version": "1.2.0",
  "created_by": "admin_user",
  "applied_at": "2025-04-05T09:00:00Z"
}

{
  "course_completion_id": "lc_444ddd",
  "user_id": "usr_xyz987",
  "course_id": "c_pldft_intro",
  "completed_at": "2025-04-05T17:30:00Z",
  "score": 92,
  "certificate_hash": "sha3:jkl012...",
  "tenant_id": "tn_abc123"
}

{
  "incident_id": "inc_555eee",
  "type": "unauthorized_access_attempt",
  "severity": "high",
  "detected_at": "2025-04-05T18:00:00Z",
  "details": {
    "source_ip": "203.0.113.5",
    "user_agent": "curl/7.68.0",
    "attempted_action": "access_case_file"
  },
  "response_taken": [
    "blocked_ip",
    "notified_secops_team"
  ],
  "closed_at": "2025-04-05T18:10:00Z"
}

{
  "metric_id": "rm_666fff",
  "tenant_id": "tn_abc123",
  "service": "risk_scoring_api",
  "metrics": {
    "requests_per_minute": 120,
    "avg_response_time_ms": 150,
    "error_rate_percent": 0.5
  },
  "recorded_at": "2025-04-05T19:00:00Z"
}

---
specVersion: '1.0'
id: onboard-screen-workflow
version: '1.0'
name: "Onboard + Screen User"
start: StartOnboarding
states:
  - name: StartOnboarding
    type: operation
    actions:
      - functionRef: "OnboardingAgent.invoke"
        arguments:
          userId: "${ .userId }"
    transition: WaitForApproval
  - name: WaitForApproval
    type: sleep
    duration: PT5S
    transition: RunScreening
  - name: RunScreening
    type: operation
    actions:
      - functionRef: "ScreeningAgent.match"
        arguments:
          userId: "${ .userId }"
    transition: GenerateReport
  - name: GenerateReport
    type: operation
    actions:
      - functionRef: "ReportingAgent.draft"
        arguments:
          userId: "$${ .userId }"
          findings: "$${ .findings }"
    end: true

---
id: risk-scoring-flow
version: '1.0'
name: "Calculate Risk Score"
start: CollectFeatures
states:
  - name: CollectFeatures
    type: operation
    actions:
      - functionRef: "FeatureStore.getFeatures"
        arguments:
          clientId: "${ .clientId }"
    transition: ComputeScore
  - name: ComputeScore
    type: operation
    actions:
      - functionRef: "RiskScorer.compute"
        arguments:
          features: "${ .features }"
    transition: NotifyIfHighRisk
  - name: NotifyIfHighRisk
    type: switch
    dataConditions:
      - condition: "${ .score.value > 0.8 }"
        transition: SendAlert
    default:
      end: true
  - name: SendAlert
    type: operation
    actions:
      - functionRef: "Notifier.send"
        arguments:
          message: "High risk client: ${ .clientId }"
    end: true

---
id: typology-matcher-flow
version: '1.0'
name: "Match Typology Hypothesis"
start: ReceiveAlertSignal
states:
  - name: ReceiveAlertSignal
    type: event
    eventRefs:
      - AlertReceived
    transition: RunInference
  - name: RunInference
    type: operation
    actions:
      - functionRef: "TypologyEngine.infer"
        arguments:
          signals: "${ .signals }"
    transition: SaveHypothesis
  - name: SaveHypothesis
    type: operation
    actions:
      - functionRef: "CaseManager.save"
        arguments:
          hypothesis: "${ .hypothesis }"
    end: true

---
id: fusion-engine-flow
version: '1.0'
name: "Fuse Signals Across Engines"
start: ListenForEvents
states:
  - name: ListenForEvents
    type: event
    eventRefs:
      - ScreeningHit
      - TransactionAnomaly
    transition: CorrelateSignals
  - name: CorrelateSignals
    type: operation
    actions:
      - functionRef: "FusionEngine.correlate"
        arguments:
          events: "${ .events }"
    transition: EmitFusionAlert
  - name: EmitFusionAlert
    type: operation
    actions:
      - functionRef: "AlertSystem.emit"
        arguments:
          fusedAlert: "${ .fusionResult }"
    end: true

---
id: regulator-access-flow
version: '1.0'
name: "Handle Regulator Access Request"
start: ValidateRequest
states:
  - name: ValidateRequest
    type: operation
    actions:
      - functionRef: "PolicyEngine.validate"
        arguments:
          requestId: "${ .requestId }"
    transition: GrantScopedAccess
  - name: GrantScopedAccess
    type: operation
    actions:
      - functionRef: "SupervisoryGateway.grant"
        arguments:
          token_ttl: "48h"
          scope: "case_read_only"
    transition: NotifyTenantOwner
  - name: NotifyTenantOwner
    type: operation
    actions:
      - functionRef: "Notifier.send"
        arguments:
          message: "Regulator accessed case."
    end: true

---
id: consent-collection-flow
version: '1.0'
name: "Collect Legal Consent"
start: ShowConsentModal
states:
  - name: ShowConsentModal
    type: operation
    actions:
      - functionRef: "UIClient.showConsent"
        arguments:
          tenantId: "${ .tenantId }"
    transition: WaitForAcceptance
  - name: WaitForAcceptance
    type: event
    eventRefs:
      - ConsentAccepted
    transition: RecordSignedConsent
  - name: RecordSignedConsent
    type: operation
    actions:
      - functionRef: "LegalAuthAgent.record"
        arguments:
          signature: "${ .signature }"
          consentType: "privacy_policy"
    end: true

Propósito

Definir la capa de producto que gestiona activos cripto y wallets, clasifica tokens/protocolos, soporta firmas on‑device, y aplica taxonomías regulatorias (e.g., VASP mapping, custodian vs non‑custodian, token risk categories). Todo con trazabilidad y evidencia para auditoría/reguladores.

ADRs relevantes

• ADR‑008 (Web3 Taxonomy) — Mantener un catálogo versionado de taxonomías de activos: token types (stablecoin, utility, governance), protocol risk labels (bridge, mixer, DEX), and custody models.
• ADR‑003 — Operaciones sensibles (e.g., bloqueo de wallet, decisión de hold) requieren aprobación humana.
• ADR‑001 — Todas las interacciones deben generar evidencia hashable para export y auditoría.

Tareas principales

• Diseño del registro de wallets y sus modelos: custodial, non‑custodial (self‑custody), hosted wallets, hardware integration (WebAuthn / Ledger / Trezor).
• Implementar flows de wallet onboarding con signature‑based KYC consent (signed consent messages), device attestation y nonce challenges.
• Crear y versionar la Taxonomía de Activos (JSON schema) y políticas de clasificación automática + manual override.
• Desarrollar token labeling pipeline: ingest token metadata (ERC/ERC‑20/721/1155 / SPL / BEP), onchain heuristics (liquidity, issuer, audits), 3rd party signals (CertiK, DeFiLlama, Chainalysis labels).
• Soporte para signatures & cryptographic proofs: signed evidence, merkle proofs for onchain snapshots, and time‑stamped attestations.
• Integración de sanciones/blacklists con onchain address resolution and offchain entities mapping (wallet ↔ entity).

Riesgos principales

Mitigantes

Criterios de aceptación (MVP)

Agentes & Sub‑agentes (estructura)

Stack tecnológico recomendado

Epics & Historias (ejemplos)

Propósito

Proveer la capa técnica y operativa para ingest, normalización y verificación de datos on‑chain y off‑chain: full‑node/archival access, RPC pooling, webhook & stream processors, indexers, token adapters, bridge/watchers y manejo de reorganizaciones (reorgs).

ADRs relevantes

• ADR‑009 (Secure Onchain Connectors) — Conectores a chains deben ser configurables, aislados por tenant y soportar failover y reconciliación de datos.
• ADR‑008 — Los metadatos de tokens deben mapearse a la taxonomía formal.

Tareas principales

• Diseñar arquitectura híbrida: node‑based ingestion (archival/full nodes) + 3rd party RPC/Indexer fallbacks (Alchemy, Infura, QuickNode, TheGraph).
• Implementar stream layer: Kafka topics por chain + domain events (tx, internal tx, logs) + indexers for token transfers and contract events.
• Crear adapters: ERC‑20/721/1155, SPL, native token parsers, bridge event parsers.
• Reorg handling & finality: design para detectar reorgs, revert/compensate events and re‑compute derived state deterministically.
• Rate limiting, caching and pagination for on‑demand lookups (balance checks, tx lookups).
• Key rotation & secrets: protect RPC keys, node credentials, and signer access; segregate per tenant when dedicated node requested.

Riesgos principales

Mitigantes

Criterios de aceptación (MVP)

Agentes & Sub‑agentes (estructura)

Stack tecnológico recomendado

Epics & Historias (ejemplos)

18 Tarjetas: Workflows (JSON/YAML) para Web3 & Blockchain Compliance

Ejemplos de definiciones de workflow (YAML/JSON) listos para usar/editar en el motor de workflows.

{
  "id": "wf_wallet_onboard_v1",
  "name": "Wallet Onboarding (Signed Consent)",
  "start": "RequestSignature",
  "states": [
    {"name":"RequestSignature","type":"operation","action":"WalletAgent.request_signature","transition":"VerifySignature"},
    {"name":"VerifySignature","type":"operation","action":"WalletAgent.verify_signature","transition":"KYCEnrich"},
    {"name":"KYCEnrich","type":"operation","action":"KYCEngine.enrich_from_registry","transition":"CreateWalletRecord"},
    {"name":"CreateWalletRecord","type":"operation","action":"WalletManager.create_record","end":true}
  ]
}

{
  "id": "wf_key_attestation_v1",
  "name": "Wallet Key Attestation (Hardware)",
  "start": "BeginAttestation",
  "states": [
    {"name":"BeginAttestation","type":"operation","action":"AttestationAgent.challenge_device","transition":"VerifyAttestation"},
    {"name":"VerifyAttestation","type":"operation","action":"AttestationAgent.verify","transition":"SaveAttestation"},
    {"name":"SaveAttestation","type":"operation","action":"WalletManager.save_attestation","end":true}
  ]
}

{
  "id": "wf_token_labeling",
  "name": "Token Labeling Pipeline",
  "start": "IngestToken",
  "states": [
    {"name":"IngestToken","type":"operation","action":"ChainAdapter.fetch_token_metadata","transition":"RunHeuristics"},
    {"name":"RunHeuristics","type":"operation","action":"TaxonomyAgent.score_token","transition":"ExternalEnrichment"},
    {"name":"ExternalEnrichment","type":"operation","action":"Enrichment.fetch_third_party","transition":"FinalizeLabel"},
    {"name":"FinalizeLabel","type":"operation","action":"TaxonomyAgent.publish_label","end":true}
  ]
}

{
  "id": "wf_tx_ingest_normalize",
  "name": "Onchain TX Ingest & Normalize",
  "start": "BlockArrival",
  "states": [
    {"name":"BlockArrival","type":"event","event":"BlockMined","transition":"ParseBlock"},
    {"name":"ParseBlock","type":"operation","action":"Indexer.parse_block","transition":"EmitTransfers"},
    {"name":"EmitTransfers","type":"operation","action":"Indexer.emit_transfer_events","end":true}
  ]
}

{
  "id": "wf_reorg_handler",
  "name": "Reorg Detection & Reconciliation",
  "start": "DetectTipChange",
  "states": [
    {"name":"DetectTipChange","type":"operation","action":"ChainConnector.check_tip","transition":"IsReorg"},
    {"name":"IsReorg","type":"switch","conditions":[{"cond":"${.is_reorg}","transition":"RollbackRange"}],"default":{"end":true}},
    {"name":"RollbackRange","type":"operation","action":"ReorgHandler.rollback_and_replay","end":true}
  ]
}

{
  "id": "wf_bridge_watcher",
  "name": "Bridge Watcher",
  "start": "EventBridgeLock",
  "states": [
    {"name":"EventBridgeLock","type":"event","event":"BridgeLock","transition":"EnrichBridgeEvent"},
    {"name":"EnrichBridgeEvent","type":"operation","action":"Enricher.enrich_bridge","transition":"ScoreBridgeRisk"},
    {"name":"ScoreBridgeRisk","type":"operation","action":"RiskEngine.score_bridge","transition":"EmitAlert"},
    {"name":"EmitAlert","type":"operation","action":"AlertSystem.emit","end":true}
  ]
}

{
  "id": "wf_mixer_detection",
  "name": "Mixer Detection",
  "start": "ReceiveTxPattern",
  "states": [
    {"name":"ReceiveTxPattern","type":"operation","action":"Analytics.detect_mixer_pattern","transition":"Score"},
    {"name":"Score","type":"operation","action":"RiskEngine.compute_mixer_score","transition":"EscalateIfHigh"},
    {"name":"EscalateIfHigh","type":"switch","conditions":[{"cond":"${.score>0.8}","transition":"CreateCase"}],"default":{"end":true}},
    {"name":"CreateCase","type":"operation","action":"CaseManager.create","end":true}
  ]
}

{
  "id": "wf_nft_laundering",
  "name": "NFT Laundering Heuristics",
  "start": "NFTTransfer",
  "states": [
    {"name":"NFTTransfer","type":"event","event":"NFTTransferEvent","transition":"EnrichNFT"},
    {"name":"EnrichNFT","type":"operation","action":"NFTAgent.fetch_provenance","transition":"ScoreNFT"},
    {"name":"ScoreNFT","type":"operation","action":"RiskEngine.score_nft","transition":"EmitAlertIfHigh"},
    {"name":"EmitAlertIfHigh","type":"switch","conditions":[{"cond":"${.score>0.7}","transition":"CreateInvestigation"}],"default":{"end":true}},
    {"name":"CreateInvestigation","type":"operation","action":"CaseManager.create","end":true}
  ]
}

{
  "id": "wf_watchlist_propagation",
  "name": "Watchlist Update & Propagation",
  "start": "WatchlistChange",
  "states": [
    {"name":"WatchlistChange","type":"operation","action":"WatchlistService.update","transition":"Propagate"},
    {"name":"Propagate","type":"operation","action":"Notifier.propagate_to_indexers","end":true}
  ]
}

{
  "id": "wf_addr_resolution",
  "name": "Address to Entity Resolution",
  "start": "NewAddress",
  "states": [
    {"name":"NewAddress","type":"operation","action":"Resolver.lookup","transition":"Enrich"},
    {"name":"Enrich","type":"operation","action":"Enricher.add_offchain_links","end":true}
  ]
}

{
  "id": "wf_sanctions_onchain_hit",
  "name": "Sanctions Address Hit",
  "start": "AddressMatched",
  "states": [
    {"name":"AddressMatched","type":"operation","action":"SanctionsEngine.match_address","transition":"CreateAlert"},
    {"name":"CreateAlert","type":"operation","action":"AlertSystem.create","transition":"NotifyTenant"},
    {"name":"NotifyTenant","type":"operation","action":"Notifier.send_tenant_alert","end":true}
  ]
}

{
  "id": "wf_chain_snapshot",
  "name": "Chain Snapshot & Merkle Proof",
  "start": "SnapshotTrigger",
  "states": [
    {"name":"SnapshotTrigger","type":"operation","action":"SnapshotService.create_block_snapshot","transition":"BuildMerkle"},
    {"name":"BuildMerkle","type":"operation","action":"ProofService.build_merkle","transition":"SignManifest"},
    {"name":"SignManifest","type":"operation","action":"SignatureService.sign","end":true}
  ]
}

{
  "id": "wf_cross_chain_correlation",
  "name": "Cross‑Chain Correlation",
  "start": "BridgeEvent",
  "states": [
    {"name":"BridgeEvent","type":"event","event":"BridgeEventDetected","transition":"LinkEvents"},
    {"name":"LinkEvents","type":"operation","action":"FusionEngine.link_cross_chain","transition":"Score"},
    {"name":"Score","type":"operation","action":"RiskEngine.score_cross_chain","end":true}
  ]
}

{
  "id": "wf_contract_migration_watch",
  "name": "Contract Migration Watch",
  "start": "ContractChange",
  "states": [
    {"name":"ContractChange","type":"operation","action":"ContractWatcher.detect_upgrade","transition":"Enrich"},
    {"name":"Enrich","type":"operation","action":"Enricher.fetch_audit_reports","transition":"ScoreUpgrade"},
    {"name":"ScoreUpgrade","type":"operation","action":"RiskEngine.score_contract_change","end":true}
  ]
}

{
  "id": "wf_token_blacklist_enforce",
  "name": "Token Blacklist Enforcement",
  "start": "BlacklistUpdate",
  "states": [
    {"name":"BlacklistUpdate","type":"operation","action":"PolicyEngine.update_blacklist","transition":"ApplyToCustodial"},
    {"name":"ApplyToCustodial","type":"operation","action":"CustodyManager.quarantine_tokens","end":true}
  ]
}

{
  "id": "wf_contract_risk_scoring",
  "name": "Smart Contract Risk Scoring",
  "start": "ContractDetected",
  "states": [
    {"name":"ContractDetected","type":"operation","action":"ContractAnalyzer.analyze","transition":"Score"},
    {"name":"Score","type":"operation","action":"RiskEngine.compute_contract_score","end":true}
  ]
}

{
  "id": "wf_regulator_onchain_evidence",
  "name": "Regulator Evidence Request — Onchain",
  "start": "RegRequest",
  "states": [
    {"name":"RegRequest","type":"operation","action":"PolicyEngine.validate_reg_request","transition":"CreateSnapshot"},
    {"name":"CreateSnapshot","type":"operation","action":"SnapshotService.create_range_snapshot","transition":"SignAndPackage"},
    {"name":"SignAndPackage","type":"operation","action":"EvidencePackager.sign_and_package","end":true}
  ]
}

{
  "id": "wf_analyst_feedback_onchain",
  "name": "Analyst Feedback — Onchain Correlation",
  "start": "AnalystFeedback",
  "states": [
    {"name":"AnalystFeedback","type":"operation","action":"FeedbackAgent.record","transition":"RetrainModel"},
    {"name":"RetrainModel","type":"operation","action":"MLTrainer.queue_retrain","end":true}
  ]
}