Projecte 4 — NeoCaixa
| Camp | Valor |
|---|---|
| Empresa | NeoCaixa (cooperativa financera 100% digital per a autònoms i pimes de la Costa Brava) |
| Sector | Fintech / banca digital |
| Nivell | Mitjà — aquí les dades importen de veritat |
| Durada estimada | 7-8 hores |
| Blocs relacionats | Bloc 4 (arquitectura), Bloc 5 (ETL i qualitat), Bloc 8 (biaix) |
Context
NeoCaixa és una cooperativa de crèdit nascuda a Blanes que dona serveis bancaris a autònoms i petites empreses de la Costa Brava (molts d'ells del sector turístic i pesquer). A diferència dels projectes anteriors, aquí un error en les dades no és només un informe incorrecte: pot significar aprovar un crèdit que mai es pagarà, o denegar-lo injustament a algú que sí que el mereixia.
Dia 1 — Transaccions en streaming i detecció de frau
Cada transacció amb targeta genera un event en temps real:
{"id_transaccio": "tx_88213", "id_client": 5021, "import": 1250.00, "comerc": "Ferreteria Blanes SL", "pais": "ES", "timestamp": "2026-06-01T22:14:03Z"}
Un patró clàssic de frau és una transacció d'import molt superior a l'habitual del client, o en un país on el client mai ha operat.
Dataset
| Fitxer | Contingut | Files |
|---|---|---|
transaccions.jsonl |
~3,5 mesos de transaccions de 300 clients, amb algunes transaccions anòmales injectades deliberadament | 6.146 |
Tasca: dissenya (pseudocodi o codi real) una tasca de streaming que calculi, per a cada transacció entrant, si l'import supera 3 desviacions estàndard per sobre de la mitjana de les últimes 90 dies d'aquell client (llindar dinàmic, com el vist al Bloc 5 per a alertes de qualitat), i que generi un event possible_frau si es compleix. Aplica-ho sobre transaccions.jsonl i comprova si detectes les transaccions amb un pais diferent d'"ES" (n'hi ha deliberadament unes quantes al fitxer).
Dia 2 — El dret a l'oblit (RGPD) sobre el Data Lake
Un client de NeoCaixa exerceix el seu dret a l'oblit (RGPD) i sol·licita l'eliminació de totes les seves dades personals. Les seves transaccions ja estan repartides en centenars de fitxers Parquet a la zona silver del Data Lake, particionats per mes.
Tasca: explica per què esborrar les dades d'un sol client d'un Data Lake de Parquet "pur" és costós (cal reescriure tots els fitxers afectats), i com un format de taula obert (Delta Lake o Apache Iceberg, vistos al Bloc 4) resol aquest problema amb una operació DELETE eficient. Escriu la comanda SQL concreta que faries servir.
Dia 3 — Feature store per al model de risc de crèdit
L'equip de risc necessita, per a cada sol·licitud de crèdit, un conjunt de features (variables) calculades a partir de l'historial del client: nombre de mesos com a client, ingressos mitjans mensuals, nombre d'incidències de pagament als últims 12 mesos...
Tasca: dissenya l'esquema d'una taula de feature store (features_risc_credit) amb com a mínim 6 columnes de features, indicant per a cadascuna si és una mètrica aditiva, semi-aditiva o no aditiva (concepte vist al Bloc 4, secció de mètriques i KPIs), i per què cal tenir-ho clar abans de calcular-la.
Dia 4 — Incident: features desactualitzades
Incident: l'equip de risc denuncia que el model de crèdit està rebutjant sol·licituds de clients que fa mesos que paguen puntualment. Investigant, es descobreix que el pipeline que actualitza features_risc_credit porta 12 dies sense executar-se amb èxit.
Tasca: proposa dues mesures (una tècnica i una organitzativa) que haguessin permès detectar aquest incident abans que ho fes un client afectat, basant-te en el contingut d'alertes i monitorització del Bloc 5 (frescor de les dades, llindars, alertes).
Dia 5 — Biaix al model de risc de crèdit
Tasca: el model de risc de crèdit s'ha entrenat amb dades històriques de concessions de préstecs de NeoCaixa dels últims 5 anys. Explica, en 4-5 línies, un risc concret de biaix que podria haver-se colat en aquestes dades (per exemple, si històricament s'han concedit menys crèdits a autònoms d'un sector concret, com la pesca artesanal, per ser considerat "de risc"), i quina mètrica de biaix (de les vistes al Bloc 8) faries servir per detectar-ho abans de posar el model en producció.
Lliurament
- Disseny de la detecció de frau en streaming (Dia 1).
- Explicació i comanda SQL del dret a l'oblit (Dia 2).
- Esquema de la taula de feature store amb classificació de mètriques (Dia 3).
- Anàlisi de l'incident i mesures de prevenció (Dia 4).
- Anàlisi de risc de biaix (Dia 5).
Mòdul M5074 Sistemes de Big Data | Institut Sa Palomera (Blanes) | Curs CEIABD 2026-2027