Skip to content

VAAS · Move KYC (Drive → S3)

Copia los expedientes de KYC (documentos de identidad/onboarding) de cada cliente de préstamo desde Google Drive a AWS S3, organizados por RFC y particionados por prestamista (LENDABLE / BBVA). La lista de clientes viene de LoanPro y el trabajo se reparte por Pub/Sub. No carga BigQuery ni PostgreSQL.

Nota de nombre: el repo se llama vass-move-kyc, pero el código, imagen y topics usan "vaas" (vaas-move-kyc-process, vaas-vault-kyc, …). No es el proveedor externo "VASS" de verificación de identidad; "VAAS" es el nombre interno de este vault/proceso. (confirmar)

¿Llegaste hasta acá desde…?

Si ves… Eso sale de… La lógica está en…
Expedientes KYC en un bucket S3 (.../expedientes/lendable|bbva/<RFC>/…) Copia desde Google Drive por este servicio vass-move-kyc → vass-move-kyc.py (/send-kyc-drive-s3)
Un cliente que no tiene expediente en S3 LoanPro custom field 279 ausente/ inválido → cliente omitido vass-move-kyc.py (/start-vaas-kyc-process, filtro por field 279)
Por qué un cliente va a lendable vs bbva LoanPro custom field 279: 1→lendable; 2/5/6→bbva vass-move-kyc.py (mapeo de field 279)

Resumen

Campo Valor
Origen Lista de clientes desde LoanPro API; archivos KYC desde Google Drive (3 carpetas padre)
Patrón Event-driven con fan-out por Pub/Sub + escritura a AWS S3 (no carga warehouse)
Destino AWS S3 (S3_BUCKET_NAME), …/expedientes/{lendable|bbva}/{RFC}/…
Frecuencia Diaria: 0 3 * * * (job vaas-start-kyc-process, /start-vaas-kyc-process) y */10 4 * * * (job vaas-search-vault, /search-vault)
Criticidad 🟢 Baja
Dueño Martin (data eng)
Repos vass-move-kyc

Diagrama de linaje

graph LR
    SCH[["⏰ Trigger (confirmar)<br/>POST /start-vaas-kyc-process"]]
    LP[["🏦 LoanPro API<br/>clientes + custom field 279"]]
    DRV[["📁 Google Drive<br/>3 carpetas padre · expedientes por RFC"]]

    subgraph svc["Cloud Run · vaas-move-kyc-process (Flask)"]
        S1["/start-vaas-kyc-process<br/><i>filtra por field 279</i>"]
        S2["/search-vault<br/><i>relay con throttle</i>"]
        S3["/send-kyc-drive-s3<br/><i>worker (push)</i>"]
    end

    T1(["Pub/Sub<br/>vaas-vault-kyc"])
    T2(["Pub/Sub<br/>vaas-send-kyc-drive-s3"])
    S3OUT["☁️ AWS S3<br/>…/expedientes/{lendable|bbva}/{RFC}/…"]

    SCH --> S1
    LP --> S1 --> T1 --> S2 --> T2 --> S3
    DRV -->|"descarga recursiva"| S3
    S3 -->|"put_object"| S3OUT

    classDef src fill:#fde68a,stroke:#b45309,color:#000;
    classDef store fill:#bfdbfe,stroke:#1e40af,color:#000;
    classDef app fill:#dcfce7,stroke:#15803d,color:#000;
    class SCH,LP,DRV src;
    class S3OUT app;

Paso a paso

  1. Etapa 1 — POST /start-vaas-kyc-process (orquestador): pagina todos los clientes de LoanPro, lee el custom field 279 de cada uno y filtra: 1→LENDABLE, 2/5/6→BBVA; cualquier otro valor / ausente → se omite. Por cada cliente válido publica un mensaje (customer_id, customerName, customId=RFC, customField279) al topic vaas-vault-kyc. Con {"process_one": true} procesa solo el primero (modo prueba).
  2. Etapa 2 — POST/GET /search-vault (relay con throttle): hace pull de la suscripción vaas-vault-kyc-sub (default 80 mensajes, 5 s entre cada uno) y republica al topic vaas-send-kyc-drive-s3, haciendo ack. Es un limitador de ritmo para no saturar al worker.
  3. Etapa 3 — POST /send-kyc-drive-s3 (worker, Pub/Sub push): decodifica el mensaje, busca en las 3 carpetas padre de Drive la subcarpeta cuyo nombre termina con el RFC, descarga recursivamente todos los archivos (cualquier tipo, no inspecciona contenido), mapea el field 279 a lendable/bbva y sube el árbol a S3 con put_object. Idempotente: si el objeto ya existe en S3 (head_object), lo omite.
  4. Diagnóstico: GET /analyze-drive-permissions, POST /analyze-s3-permissions (comandos analyze/count/search/ls), GET /health.

Nota: este flujo no pasa por dbt ni BigQuery. La lógica vive en vass-move-kyc.py; el resultado se consume en el destino S3 (sistema de expedientes — confirmar).

Tablas que alimenta

No alimenta tablas de BigQuery. Destino: AWS S3 (S3_BUCKET_NAME), bajo el prefijo <UUID hardcodeado>/expedientes/{lendable|bbva}/{RFC}/….

Consumo aguas abajo

  • El bucket S3 de expedientes lo consume otro sistema/producto (confirmar cuál). No hay consumo analítico en el warehouse.

Contexto / autoría: este proceso lo construyó Jean (j.tapias); es el primer contacto para dudas de diseño o del destino real del bucket. (Búsqueda en Slack no arrojó un hilo técnico claro a la fecha.)

Si falla 🛠️

Impacto: bajo (migración de archivos KYC). Si falla, expedientes no quedan copiados en S3. Pub/Sub reintenta los push fallidos; la etapa 3 es idempotente.

Síntoma Dónde mirar Acción
No se copian expedientes nuevos Logs Cloud Run del servicio (/start-…, /search-vault, /send-…) Confirmar trigger (Cloud Scheduler) y que las 3 etapas corren en orden
Cliente "omitido" / sin expediente LoanPro custom field 279 de ese cliente Field ausente o valor no mapeado (≠1/2/5/6); revisar del lado de LoanPro
No encuentra carpeta en Drive Permisos del service account sobre las 3 carpetas padre (/analyze-drive-permissions) Compartir las carpetas con la cuenta de servicio
Error al subir a S3 AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY / AWS_REGION / S3_BUCKET_NAME Verificar credenciales y bucket (/analyze-s3-permissions)

Escalación: dudas de diseño/contexto → Jean (j.tapias), autor del proceso · resto → Martin (coordinar con el dueño del bucket de expedientes / producto).

Enlaces

  • 📊 Estado en vivo: dashboard "Data Processes" (Cloud Monitoring)
  • 📦 Servicio: vass-move-kyc — main vass-move-kyc.py (imagen vaas-move-kyc-process)

Última actualización: 2026-06-21 · Si cambia el flujo, las carpetas de Drive, el bucket S3 o el ruteo por field 279, actualizar esta ficha en el mismo MR.