Fintonic

Fintonic Money, S.L. fue una startup del sector fintech con sede en Barcelona, constituida en el año 2011. Según el registro, su capital social era de 46.000 EUR y su situación registral final es la de empresa adquirida. La actividad se desarrolló durante diez años, hasta 2021.

La sociedad se constituyó el 1 de enero de 2011 en Barcelona. Los cofundadores que constan son Eduardo Pérez, que ejercía de consejero delegado (CEO), y Sergi Herrera. No constan en los datos disponibles más detalles sobre el proceso de constitución, el capital inicial ni las rondas de financiación previas.

Según la información disponible, Fintonic era una fintech. Los datos facilitados no detallan con precisión el producto ni el segmento de clientes, más allá de que su producto fue absorbido dentro de la banca digital de BNP Paribas tras la adquisición. Cualquier descripción más concreta del servicio requeriría consultar la fuente citada o documentación adicional, que no consta en este corpus.

No consta en los datos disponibles información sobre la evolución de la facturación, el número de usuarios, las rondas de financiación ni los resultados económicos durante los diez años de actividad. El único elemento que indica una trayectoria relevante es el hecho de que una entidad financiera como BNP Paribas adquiriera el producto en 2021.

La causa verificada del cese es la adquisición. En junio de 2021, el acto registral de "FUSIONES Y ABSORCIONES" recoge la adquisición por parte de BNP Paribas, que absorbió el producto dentro de su banca digital. Por tanto, no se trata de un cierre por quiebra sino de una integración en una entidad más grande, de acuerdo con el registro.

El producto de Fintonic quedó integrado dentro de la banca digital de BNP Paribas a raíz de la adquisición de 2021. Los datos disponibles no permiten detallar qué parte del producto, de la marca o del equipo se mantuvo tras la integración.

Los datos del corpus solo identifican a Eduardo Pérez (cofundador y CEO) y Sergi Herrera (cofundador). No consta cuál es su situación actual ni si continuaron vinculados a BNP Paribas tras la integración. Para completar esta información habría que consultar el registro mercantil actualizado, las notas de prensa de la operación y perfiles profesionales públicos, ninguno de los cuales forma parte de este corpus.

• En una fintech de consumo, la salida por adquisición por parte de una entidad bancaria consolidada es una vía de continuidad del producto, pero implica que la marca y el equipo pasan a depender de la estrategia del comprador; conviene prever contractualmente el destino del producto y del equipo.
• La integración dentro de una banca digital conlleva absorber el producto en una estructura regulada; conviene documentar desde el principio la titularidad de la tecnología y las licencias para facilitar la operación.
• Para una startup con capital social reducido (46.000 EUR en este caso), el valor de la operación radica en el producto y la base de usuarios, no en el balance; esto hace especialmente relevante medir y documentar métricas de uso antes de negociar.
• La información pública disponible sobre operaciones de este tipo suele ser escasa; mantener un registro interno ordenado de hitos registrales y financieros facilita reconstruir la trayectoria cuando sea necesario.

Reconstruir l'essència de Fintonic avui significa partir d'una base verificada: una app que agregava comptes bancaris de l'usuari, li donava visibilitat sobre les seves finances i monetitzava orientant-lo cap a productes financers (crèdit, estalvi, assegurances). Això és el que l'empresa va fer durant deu anys fins a la seva adquisició per BNP Paribas el 2021, segons la cronologia registral i la font disponible.

La proposta (nova, no verificada) seria una capa de finances personals "privacy-first" i mòbil, que combini:

• Agregació de comptes via open banking (PSD2), que avui és infraestructura estàndard a la UE.
• Un motor d'insights de despesa i alertes predictives.
• Un marketplace de productes financers amb ingressos per comissió o lead.

La diferència respecte al Fintonic original no seria el concepte sinó el context: el 2011 calia educar el mercat; avui l'open banking és regulat i estès, cosa que redueix fricció tècnica però augmenta competència (neobancs, agregadors incrustats als bancs).

El mercat rellevant és el de gestió de finances personals i distribució digital de productes financers a Espanya i, potencialment, a la UE. Dades verificades: Fintonic va operar deu anys i va ser adquirida per un banc sistèmic el 2021, la qual cosa indica que el model tenia valor estratègic per a un incumbente (captació de clients i dades), encara que no necessàriament rendibilitat autònoma —aquest punt no consta a les fonts i no s'afirma.

Com a estimació a validar: el nínxol d'usuaris digitals que volen veure tots els seus comptes en un sol lloc i rebre ofertes de crèdit personalitzades continua existint, però avui està disputat per:

• Neobancs que ja inclouen agregació.
• Apps natives dels bancs.
• Agregadors incrustats (B2B2C) venuts a tercers.

La lectura estratègica: el valor ja no és "ser l'app de finances personals", sinó "ser la capa que connecta usuaris amb productes financers allà on ja són".

Model proposat (a validar), inspirat en la monetització típica del sector i coherent amb l'essència de Fintonic:

1. Comissió per lead/oferta de productes financers (crèdit, assegurances, estalvi). És la font principal en aquest tipus de negoci.
2. Subscripció premium per funcions avançades (pressupostos, alertes, informes). Ingrés recurrent però de volum limitat.
3. Llicenciament B2B de la capa d'agregació i insights a tercers (fintechs, retail, mitjans). Model alternatiu o complementari.

Estimació de rangs (a validar, no són dades de Fintonic): comissió per lead de producte financer en un rang orientatiu de desenes d'euros per lead qualificat; conversió a subscriptció premium en un dígit baix percentual de la base d'usuaris. Aquestes xifres s'han de contrastar amb el mercat abans de qualsevol pla financer.

Fases proposades (no verificades, és un pla nou):

1. Fase 0 — Validació (mesos 0–3): entrevistes a usuaris, definició del nínxol (p. ex. joves amb múltiples comptes o autònoms), i prototip de només lectura via open banking.
2. Fase 1 — MVP (mesos 3–9): agregació de comptes, categorització de despesa i alertes. Sense monetització agressiva; objectiu: retenció i dada.
3. Fase 2 — Monetització (mesos 9–15): marketplace de productes amb acords de comissió i primer nivell premium.
4. Fase 3 — Escala (mesos 15–24): màrqueting de creixement, possible obertura a un segon mercat de la UE i exploració del canal B2B.

Punt crític de lliçó apresa: Fintonic va acabar absorbida per un banc; el pla nou hauria de decidir des del dia 1 si l'objectiu és independència rendible o ser una peça atractiva per a un incumbente (estratègia de sortida).

Xifres estimades i a validar (no són dades de Fintonic ni del seu balanç):

• Equip mínim (2 enginyers, 1 producte, 1 negoci): rang estimat de 250.000–450.000 €/any en cost de personal a Barcelona.
• Desenvolupament de MVP amb open banking (integracions, compliment PSD2, seguretat): rang estimat de 150.000–400.000 €.
• Compliment normatiu i legal (RGPD, PSD2, contractes amb proveïdors d'agregació): rang estimat de 30.000–80.000 € inicials.
• Màrqueting de llançament i adquisició primerenca: rang estimat de 100.000–300.000 €.
• Cost total d'arrencada fins a MVP monetitzable: rang estimat d'1,5–3,5 M€, a validar segons abast i equip.

Nota: el capital social registrat de Fintonic era de 46.000 €, dada que no reflecteix el cost real de construir un producte com aquest i no s'ha d'usar com a referència de pressupost.

• Risc competitiu: els bancs i neobancs ja ofereixen agregació; cal un angle diferenciador clar.
• Risc regulatori: PSD2, RGPD i possibles canvis en open banking exigeixen compliment continu.
• Risc de monetització: la comissió per lead depèn de la voluntat dels proveïdors de productes financers de pagar per canal digital.
• Risc de confiança: l'usuari ha de cedir accés als seus comptes; qualsevol incident de seguretat és crític.
• Risc de sortida: com va passar amb Fintonic, l'èxit pot acabar en absorció per un incumbente; cal decidir si això és un objectiu o un risc.

Lliçons de l'informe original (no un currículum):

• Fintonic va demostrar que un equip fundador petit pot construir un producte financer rellevant a Barcelona durant una dècada.
• La sortida via adquisició per un banc indica que el valor del negoci era estratègic (clients i dades) més que no pas rendibilitat autònoma demostrada a les fonts.
• Per reconstruir-ho avui caldria un equip amb capacitat tècnica en open banking, criteri de producte per a finances personals i una decisió clara sobre el model de sortida.
• La lliçó central: en fintech de consum, la distribució i la confiança pesen tant com el producte; qui ho construeixi ha de planificar la monetització i la possible absorció des del primer dia.

Un usuari amb diversos comptes en entitats diferents no té una visió única dels seus diners: cada banc mostra només la seva part, els extractes són heterogenis i les despeses recurrents (subscripcions, quotes) passen desapercebudes. Fintonic resolia això agregant comptes en un sol lloc i convertint moviments en informació útil (categoria, pressupost, alerta). El producte a construir ha de resoldre el mateix nucli: ingesta fiable de moviments de múltiples bancs, normalització, categorització automàtica i regles de pressupost/alerta sobre aquestes dades.

La font disponible ([Wikipedia] Fintonic) descriu l'empresa com una startup de software i SaaS amb seu a Barcelona, dedicada a la gestió de finances personals. Aquesta especificació no replica detalls interns no documentats; defineix una arquitectura pròpia i implementable que cobreix la funcionalitat descrita.

Arquitectura de microserveis amb un nucli de dades financeres transaccional i serveis satèl·lit al voltant. El motiu és separar el domini crític (moviments i saldos, que han de ser consistents i auditables) dels processos eventualment consistents (categorització, alertes, notificacions), que poden reintentar-se sense afectar la veritat comptable.

Components:

``` [Apps client: iOS / Android / Web] | v [API Gateway + Auth (OIDC, JWT)] -- rate limiting, mTLS intern | +--> [Servei Comptes] (comptes, saldos, consentiments) +--> [Servei Moviments] (ingesta, deduplicació, normalització) +--> [Servei Categorització] (regles + model ML) +--> [Servei Pressupostos] (límits, càlcul de consum) +--> [Servei Alertes] (regles, notificacions) | v [Broker d'esdeveniments: Kafka] | v [Agregador PSD2] <--> [Bancs via APIs PSD2 / TPP] | v [PostgreSQL (nucli)] + [Object storage (extractes)] + [Redis (cache)] ```

Decisions i motius:

• PostgreSQL com a magatzem del nucli financer: transaccions ACID i restriccions d'integritat són imprescindibles per a moviments i saldos; un magatzem eventualment consistent aquí generaria descuadres difícils de reconciliar.
• Kafka per a esdeveniments de moviment: la categorització, els pressupostos i les alertes depenen del mateix flux de moviments; un log d'esdeveniments permet consumidors independents i reprocessament (per exemple, recategoritzar historial quan canvia el model).
• Agregador PSD2 com a servei aïllat: els consentiments i les crides a bancs tenen cicles de vida i errors propis (tokens caducats, APIs caigudes); aïllar-los evita que la indisponibilitat d'un banc bloquegi la resta del producte.
• Idempotència a la ingesta: els bancs poden retornar el mateix moviment diverses vegades; cal una clau natural per evitar duplicats.

Esquema relacional al nucli (PostgreSQL). Taules principals:

```sql -- Usuaris i consentiments users(id UUID PK, email, created_at) consents(id UUID PK, user_id FK, bank_id, psu_ip, granted_at, expires_at, status ENUM('active','expired','revoked'))

-- Comptes i saldos accounts(id UUID PK, user_id FK, bank_id, external_id, iban_hash, type ENUM('checking','savings','card'), currency CHAR(3), balance NUMERIC(18,2), balance_at TIMESTAMPTZ, UNIQUE(bank_id, external_id))

-- Moviments (nucli) transactions(id UUID PK, account_id FK, external_id, booked_at TIMESTAMPTZ, amount NUMERIC(18,2), currency CHAR(3), description_raw TEXT, counterparty TEXT, direction ENUM('debit','credit'), category_id FK NULL, category_source ENUM('rule','ml','user'), dedup_hash CHAR(64), UNIQUE(account_id, dedup_hash))

-- Categorització categories(id UUID PK, parent_id FK NULL, name, kind) rules(id UUID PK, user_id FK NULL, priority INT, match_type ENUM('contains','regex','counterparty'), pattern TEXT, category_id FK)

-- Pressupostos i alertes budgets(id UUID PK, user_id FK, category_id FK, period ENUM('monthly'), limit_amount NUMERIC(18,2), currency CHAR(3)) alerts(id UUID PK, user_id FK, type, threshold, channel, active BOOL) ```

Decisions i motius:

• `dedup_hash` calculat sobre (data valor, import, descripció normalitzada, contrapart) per garantir idempotència a la ingesta; `UNIQUE(account_id, dedup_hash)` impedeix duplicats a nivell de base de dades.
• `category_source` per traçar si la categoria ve de regla, model o correcció manual; les correccions de l'usuari tenen prioritat i alimenten el model.
• `iban_hash` en lloc de l'IBAN en clar per minimitzar dades sensibles (pseudonimització).
• Imports en `NUMERIC(18,2)` i moneda explícita per evitar errors d'arrodoniment i suportar multicurrency.

API pública (REST/JSON, versionada `/v1`) per a clients:

``` GET /v1/accounts GET /v1/accounts/{id}/transactions?from=&to=&category= GET /v1/transactions/{id} PATCH /v1/transactions/{id} # reassignar categoria (manual) GET /v1/budgets?period=2025-06 POST /v1/budgets GET /v1/alerts POST /v1/consents # iniciar enllaç bancari DELETE /v1/consents/{id} # revocar ```

Integració PSD2: el servei Agregador parla amb APIs de bancs (AIS — Account Information Service) sota llicència de TPP o via un proveïdor agregador. Flux:

1. L'usuari inicia consentiment; es redirigeix al banc (SCA).
2. Es desa el consentiment amb `expires_at` (típicament 90 dies).
3. Un planificador fa polling o rep webhooks de nous moviments segons el banc.
4. Cada moviment es publica a Kafka (`transactions.ingested`).

Decisions i motius:

• Consentiments amb caducitat explícita: la normativa PSD2 limita la validesa; modelar-ho evita crides fallides i permet avisar l'usuari abans que caduqui.
• *Webhooks quan el banc els ofereix, polling com a fallback*: redueix latència i càrrega, però no tots els proveïdors ofereixen push.
• API versionada: els clients mòbils triguen a actualitzar-se; cal compatibilitat enrere.

Ordre de construcció per obtenir valor real el més aviat possible:

1. Auth i model d'usuaris (OIDC, JWT) — base de tot.
2. Ingesta d'un sol banc via agregador PSD2 amb deduplicació i normalització de moviments. Motiu: sense dades reals no es pot validar res; un sol banc és suficient per provar el pipeline.
3. Llistat de comptes i moviments (API + client mínim). Motiu: és el valor immediat per a l'usuari.
4. Motor de categorització per regles (no ML encara). Motiu: les regles cobreixen la majoria de casos i són explicables i depurables; el ML s'afegeix quan hi ha volum de dades etiquetades.
5. Pressupostos i alertes bàsiques sobre categories.
6. Ampliació a més bancs i model ML de categorització.

Mides orientatives (per dimensionar, no compromeses):

• Ingesta: desenes de milers de moviments/dia per cada 100k usuaris actius; pics a inici de mes.
• Emmagatzematge: ~1 KB per moviment normalitzat; retenció de 5 anys per requisits financers.
• Latència objectiu: lectura de moviments < 300 ms p95; alerta generada < 1 min des de la ingesta.

Riscos tècnics i mitigació:

• Fiabilitat dels bancs: APIs PSD2 inestables o amb downtime. Mitigació: cues de reintent amb backoff, estat de salut per banc, degradació gràcil (mostrar dades de l'última sincronització).
• Qualitat de categorització: descripcions brutes i heterogènies. Mitigació: normalització + regles + correcció manual que retroalimenta el model; mètrica de precisió per categoria.
• Compliment i privacitat: dades financeres sensibles sota GDPR/PSD2. Mitigació: xifrat en repòs i trànsit, pseudonimització d'IBAN, minimització de dades, audit log d'accessos.
• Duplicats i descuadres: mitigat per `dedup_hash` i reconciliació periòdica de saldos.
• Cost de l'agregador: les crides PSD2 tenen cost; cal cache i freqüència de sincronització ajustada.

• Tests d'integració amb bancs sandbox: cada agregador ofereix entorn de proves; validar consentiment, ingesta i caducitat.
• Tests de propietat sobre deduplicació: generar moviments repetits i verificar que la base de dades en manté un de sol.
• Tests de reconciliació de saldos: comparar saldo calculat (suma de moviments) amb saldo reportat pel banc; alertar si divergeix.
• Avaluació del motor de categorització: conjunt etiquetat manualment; mesurar precisió/recall per categoria i fixar un llindar d'acceptació abans de desplegar canvis de model.
• Tests de càrrega sobre la ingesta i les lectures de moviments als pics d'inici de mes.
• Auditoria de seguretat i revisió de compliment (GDPR/PSD2) abans de producció amb dades reals.
• Criteri d'acceptació del MVP: un usuari pot enllaçar un banc, veure comptes i moviments categoritzats, definir un pressupost i rebre una alerta en superar-lo, amb dades consistents després de 7 dies de sincronització.