Bienvenido a NeoBank

### El salto a la banca — donde un NULL puede costar millones

AdPulse fue un máster en fuentes de datos heterogéneas y reconciliación. Aprendiste a lidiar con 3 APIs distintas, a construir modelos de atribución multi-touch y a presentar resultados a un cliente que no sabe SQL pero sí sabe cuándo un número no cuadra. Carmen te enseñó que "los datos cuadran" es una decisión de ingeniería, no un hecho natural. Raúl te mostró que las discrepancias entre fuentes siempre existen — la pregunta es si las gestionas o las ignoras.

Pero siempre quisiste trabajar en algo donde los datos IMPORTAN de verdad — donde un NULL en el campo equivocado puede bloquear una transacción de 50.000 euros, donde un pipeline roto a las 3AM puede significar que 200.000 personas no pueden pagar su hipoteca, donde una brecha de datos no es "mala prensa" sino una multa de 3.8 millones de euros.

Alberto Reyes, arquitecto de datos de NeoBank, te contactó por LinkedIn un martes a las 11 de la noche. Su mensaje era directo: "He visto tu perfil — alguien que ha trabajado con múltiples fuentes, reconciliación y calidad de datos en un entorno exigente. Eso es exactamente lo que necesitamos. Aquí los datos no van a dashboards bonitos — van a decisiones regulatorias y modelos de fraude que mueven millones cada día. ¿Tomamos un café?" Tres semanas después, firmaste el contrato. El primer día es hoy.

### NeoBank — Banco 100% digital

NeoBank nació en 2020 de la mano de tres ex-directivos de BBVA y N26 que veían una oportunidad clara: la banca española seguía anclada en oficinas físicas y experiencias digitales mediocres. Un banco que naciera 100% digital, sin sucursales, sin papel, sin colas — solo una app nativa impecable y una cuenta operativa en 5 minutos. Obtuvieron la licencia bancaria del Banco de España en 2021 (un proceso de 14 meses con 847 páginas de documentación que casi mata la empresa) y lanzaron al público en marzo de 2022.

El crecimiento fue explosivo: 500K clientes en el primer año, 1 millón en 18 meses, 2.1 millones ahora. La clave fue una combinación letal: cero comisiones en la cuenta básica, notificaciones instantáneas de cada movimiento (0.3 segundos después de la transacción), y la mejor app de banca en España según los usuarios de las tiendas de apps. Acaban de cerrar una Serie D de 120M euros liderada por SoftBank. El objetivo para 2025: lanzar hipotecas digitales y créditos al consumo — productos regulados que multiplican la complejidad de datos por 10.

• ▹Clientes activos: 2.1 millones (crecimiento de 80K/mes)
• ▹Transacciones/día: ~4.5 millones (~52 eventos/segundo en Kafka, picos de 200/s)
• ▹Volumen transado/mes: ~2.800M EUR (33.600M EUR anuales)
• ▹Empleados: ~300 personas (equipo de datos: 6 personas)
• ▹Regulador: Banco de España + BCE (reportes COREP/FINREP mensuales obligatorios)
• ▹Productos: cuenta corriente, tarjeta débito/crédito, SEPA, Bizum, préstamos personales
• ▹Infraestructura: 100% AWS, multi-AZ eu-west-1, encriptación at-rest y in-transit obligatoria

### El stack tecnológico

NeoBank tiene un stack moderno pero con decisiones muy deliberadas. Todo está justificado con ADRs (Architecture Decision Records) porque el regulador puede preguntar "¿por qué usáis esta tecnología para datos financieros?" y necesitas una respuesta documentada.

• ▹Ingesta: Amazon MSK (Kafka managed) — topic transactions.completed (~52 eventos/seg)
• ▹Data Lake: AWS S3 con 3 zonas (raw/silver/gold) — ~45TB total, encriptación AES-256
• ▹Procesamiento batch: PySpark en EMR — 8 jobs diarios, cluster de 12 nodos
• ▹Warehouse: Amazon Redshift (ra3.xlplus) — 14 tablas gold, 3TB comprimidos
• ▹Orquestación: Apache Airflow 2.8 en ECS — 34 DAGs activos
• ▹Calidad: Great Expectations — 6 checkpoints críticos en el pipeline
• ▹Feature Store: Redis 7 (hot) + S3 Parquet (cold) — casero, sin Feast
• ▹Modelo de fraude: scikit-learn + XGBoost, serving en SageMaker endpoint
• ▹Infraestructura: Terraform 1.6 — TODO versionado en GitHub, PRs obligatorios
• ▹Monitoring: CloudWatch + Datadog — alertas PagerDuty con escalación en 5 min

### Tu equipo

El equipo de datos de NeoBank es pequeño pero senior. No hay juniors — tú eres la persona con menos experiencia y ya llevas 10 meses en la industria (FreshMart + TaskFlow + AdPulse). La razón es simple: en banca, un error en datos puede generar una multa de millones o bloquear transferencias de clientes. Alberto contrata con cuidado — prefiere 6 personas senior a 12 juniors.

### Los personajes

Alberto Reyes (38) — Data Architect, tu jefe directo. Ex-Revolut Londres (3 años), ex-ING España (2 años). Piensa en sistemas, no en tareas. Cuando le presentas una solución, su primera pregunta siempre es: "¿Y qué pasa si escala a 10x?" No acepta "funciona" como respuesta — quiere saber POR QUÉ funciona y QUÉ puede romperlo. Es exigente pero justo: si justificas una decisión con datos y trade-offs claros, la respeta incluso si él habría elegido otra opción. Lleva un cuaderno Moleskine donde dibuja diagramas de arquitectura y tiene un borrador de libro sobre "Data Architecture for Regulated Industries" que nunca termina de escribir.

Sara Vidal (42) — Compliance Officer y DPO (Data Protection Officer). Ex-inspectora de la Agencia Española de Protección de Datos (AEPD) durante 6 años. Se pasó al sector privado porque "es más efectivo prevenir desde dentro que sancionar desde fuera". Abogada de formación reconvertida a datos regulatorios. Formal, precisa, siempre con copia a Legal en cada email. Para ella, la ley no es negociable: si el RGPD dice 30 días, son 30 días, no 31. No es tu enemiga; es la persona que evita que NeoBank reciba una multa del 4% de facturación (3.8M EUR). Aprende a trabajar CON ella, no contra ella.

Miguel Ortiz (30) — ML Engineer del equipo de fraude. PhD en Machine Learning por la UPC, 2 años en Stripe (San Francisco), volvió a España "porque la calidad de vida no tiene precio". Impaciente, habla en jerga ML ("necesito features con ventana deslizante de 1h, target encoding del merchant y el ratio txn/hora"). Necesita los datos RÁPIDO porque cada hora sin features actualizadas es una hora donde el modelo de fraude pierde precisión. Su modelo levanta unas 280 alertas al día y bloquea unos 78 fraudes reales — el resto son falsos positivos, y ése es su otro problema. Cuando se queda sin features frescas, se le escapa casi uno de cada cuatro. Cada fraude medio: 3.200 EUR.

Clara Mendoza (45) — VP de Data. Reporta directamente al CEO. Ex-BBVA (8 años), ex-McKinsey (3 años). Preside el Architecture Review Board (ARB) semanal. Dura pero justa: si presentas bien, te apoya con presupuesto y recursos. Si presentas mal, te manda de vuelta con un "vuelve cuando tengas números". No le interesan los detalles técnicos — quiere saber impacto en negocio, riesgo y coste.

Paula García (35) — Senior Data Engineer. 5 años en NeoBank (desde antes de tener licencia bancaria). Conoce cada rincón del sistema. Tu compañera de on-call — cuando algo se rompe a las 3AM, ella es quien te guía por el laberinto de logs y métricas. Pragmática: "Lo perfecto es enemigo de lo bueno, pero lo chapucero es enemigo de dormir tranquilo." Tiene tres hijos pequeños, así que su tolerancia a incidentes evitables es exactamente cero.

### Los 4 problemas de esta semana

Alberto te sienta en la sala Turing (todas las salas tienen nombres de científicos) el primer día y te explica la situación sin rodeos. Tiene la pizarra llena de post-its rojos:

1Alberto Reyes (pizarra, 9:15 AM):
2"No te voy a mentir. Te he fichado porque necesitaba a alguien
3polivalente que pudiera trabajar en streaming Y regulación. Esta
4semana tienes 4 frentes abiertos. Prioriza, pide ayuda cuando la
5necesites, y documenta todo. Si no puedes con algo, me lo dices el
6martes -- no el viernes."
7
8"Estos son tus 4 problemas:
9
101. STREAMING: El pipeline batch tiene latencia de 4-28 horas.
11   Miguel necesita features de fraude en <5 min. El BdE necesita
12   alertas de transacciones sospechosas en <15 min. Necesito que
13   evalúes opciones, escribas un ADR y me traigas un prototipo.
14
152. GDPR: Sara tiene una petición de borrado. Artículo 17. Deadline
16   legal de 20 días. No existe proceso automatizado. Hay que crearlo.
17
183. FEATURE STORE: Miguel necesita 5 features materializadas para su
19   modelo. 3 hot (ventana 1h), 1 warm (24h), 1 cold (30d). No hay
20   feature store -- hay un script de Redis que se rompe cada semana.
21
224. ON-CALL: Esta semana estás de guardia con Paula. Si algo se rompe
23   a las 3AM, eres tú quien responde. El pipeline de streaming que
24   despliegues... lo operas tú."

1. 01.STREAMING: Pipeline batch con latencia 4-28h. SLA de fraude: <5 min. SLA regulatorio: <15 min. Migrar a near-real-time con Spark Structured Streaming sobre Kafka MSK.
2. 02.GDPR: Cliente acc_00028473 ejerció derecho al olvido (art. 17 RGPD). Plazo legal: 30 días (quedan 20). Anonimizar irreversiblemente en 6 tablas + S3. Crear proceso repetible.
3. 03.FEATURE STORE: 5 features para el modelo de fraude. 3 hot con ventana 1h (Redis), 1 warm 24h (Redis TTL), 1 cold batch 30d (Redshift). Diseñar arquitectura hot/warm/cold.
4. 04.ON-CALL: Rotación de guardia. Si el pipeline se cae, respondes tú. Incident management real con timeline, hotfix y post-mortem.

### Por qué en banca el dato tarde es un dato malo, y no solo incómodo

En FreshMart, en TaskFlow y en AdPulse, un dato que llegaba tarde era un dato incómodo: alguien tomaba una decisión peor, y se corregía la semana siguiente. En banca no funciona así, y conviene entender por qué antes de tocar nada.

Un dato tarde es un dato que ya no sirve para su propósito. Una alerta de fraude a las tres horas no es «una alerta con retraso»: es una alerta inútil, porque el dinero ya salió. Una notificación al supervisor fuera de plazo no es «una notificación tardía»: legalmente es una notificación que no se hizo.

Eso cambia tres cosas de cómo trabajas:

• ▹La latencia es un requisito, no una métrica de calidad. «5 minutos» no es un objetivo al que aspirar: es la definición de que el sistema funciona. Por debajo, funciona; por encima, está caído aunque no dé ningún error.
• ▹Los reprocesos tienen huella. Volver a cargar un día de datos en un almacén normal es rutina. Aquí, si de ese dato salieron notificaciones al regulador o bloqueos de tarjeta, el reproceso tiene que dejar constancia de qué cambió y por qué. Por eso todo lleva ADR: no es burocracia, es la respuesta que hay que dar cuando alguien pregunte dentro de dos años.
• ▹Borrar de verdad es un problema técnico. El derecho al olvido del artículo 17 no se cumple con un DELETE: hay copias en S3, en el almacén, en Redis, en los backups y en los logs. La lección del miércoles va de eso, y es más difícil de lo que parece.

La pregunta que te va a hacer Alberto en cada revisión no es «¿funciona?», sino «¿cómo sabes que funciona, y qué pasa el día que no?». Ir con la respuesta preparada es la diferencia entre un mid y un junior con tres años.

### La semana por delante — del martes 17 al viernes 20 de septiembre

• ▹Día 1 (Martes): Streaming — evaluar opciones, escribir el ADR
• ▹Día 2 (Miércoles): GDPR — inventariar PII, diseñar proceso de supresión con SHA-256 + salt efímero
• ▹Día 3 mañana (Jueves, 10:00): Architecture Review — defender el ADR ante Clara
• ▹Día 3 mañana (Jueves, 11:00): Feature Store — diseñar arquitectura hot/warm/cold para ML en producción
• ▹Día 3 tarde (Jueves): Implementar streaming con Spark Structured Streaming + watermarks
• ▹Día 4 (Viernes 3AM): EL INCIDENTE — un solo cliente tumba el pipeline, diagnosis, hotfix, comunicación
• ▹Día 5 (Viernes): Post-mortem profesional + acciones preventivas + demo a stakeholders
• ▹Retrospectiva: Skills ganadas, evolución profesional, preparación para FlashRoute

Bienvenido a NeoBank. Aquí los datos no son métricas de vanidad ni KPIs en un dashboard que nadie mira. Son dinero real de personas reales. Son hipotecas, nóminas, ahorros de toda una vida. Prepara café. Lo vas a necesitar.