Fintonic

Fintonic Money, S.L. fou una startup del sector fintech amb seu a Barcelona, constituïda l'any 2011. D'acord amb el registre, el seu capital social era de 46.000 EUR i la seva situació registral final és la d'empresa adquirida. L'activitat es va desenvolupar durant deu anys, fins al 2021.

La societat es va constituir l'1 de gener de 2011 a Barcelona. Els cofundadors que consten són Eduardo Pérez, que exercia de conseller delegat (CEO), i Sergi Herrera. No consten a les dades disponibles més detalls sobre el procés de constitució, el capital inicial ni les rondes de finançament prèvies.

Segons la informació disponible, Fintonic era una fintech. Les dades facilitades no detallen amb precisió el producte ni el segment de clients, més enllà que el seu producte fou absorbit dins de la banca digital de BNP Paribas després de l'adquisició. Qualsevol descripció més concreta del servei requeriria consultar la font citada o documentació addicional, que no consta en aquest corpus.

No consta en les dades disponibles informació sobre l'evolució de la facturació, el nombre d'usuaris, les rondes de finançament ni els resultats econòmics durant els deu anys d'activitat. L'únic element que indica una trajectòria rellevant és el fet que una entitat financera com BNP Paribas n'adquirís el producte el 2021.

La causa verificada del cessament és l'adquisició. El juny de 2021, l'acte registral de "FUSIONES Y ABSORCIONES" recull l'adquisició per part de BNP Paribas, que va absorbir el producte dins de la seva banca digital. Per tant, no es tracta d'un tancament per fallida sinó d'una integració en una entitat més gran, d'acord amb el registre.

El producte de Fintonic va quedar integrat dins de la banca digital de BNP Paribas arran de l'adquisició del 2021. Les dades disponibles no permeten detallar quina part del producte, de la marca o de l'equip es va mantenir després de la integració.

Les dades del corpus només identifiquen Eduardo Pérez (cofundador i CEO) i Sergi Herrera (cofundador). No consta quina és la seva situació actual ni si van continuar vinculats a BNP Paribas després de la integració. Per completar aquesta informació caldria consultar el registre mercantil actualitzat, les notes de premsa de l'operació i perfils professionals públics, cap dels quals no forma part d'aquest corpus.

• En una fintech de consum, la sortida per adquisició per part d'una entitat bancària consolidada és una via de continuïtat del producte, però implica que la marca i l'equip passen a dependre de l'estratègia del comprador; cal preveure contractualment el destí del producte i de l'equip.
• La integració dins d'una banca digital comporta absorbir el producte en una estructura regulada; convé documentar des del principi la titularitat de la tecnologia i les llicències per facilitar l'operació.
• Per a una startup amb capital social reduït (46.000 EUR en aquest cas), el valor de l'operació rau en el producte i la base d'usuaris, no en el balanç; això fa especialment rellevant mesurar i documentar mètriques d'ús abans de negociar.
• La informació pública disponible sobre operacions d'aquest tipus sol ser escassa; mantenir un registre intern ordenat de fites registrals i financeres facilita reconstruir la trajectòria quan calgui.

El que Fintonic feia el 2011 —connectar-se als comptes de l'usuari, categoritzar moviments i donar-li una visió única de la seva situació financera— avui és una commodity tècnica. La directiva PSD2 i les APIs bancàries obertes han convertit l'agregació en un servei que es compra per API (estimació: entre 0,10 i 0,50 EUR per compte connectat i mes, segons volum, a validar amb proveïdors tipus Tink, GoCardless o similars).

Per tant, la idea no és "tornar a fer Fintonic per al consumidor". És construir la capa de salut financera personal que la banca mitjana i les cooperatives de crèdit no poden o no volen desenvolupar internament, i vendre-la com a producte blanc. El nucli és el mateix: agregació, categorització, alertes, projecció de flux de caixa i un "score" de salut financera. El que canvia és qui paga: no l'usuari final, sinó l'entitat financera que vol retenir i fidelitzar clients.

Això és una proposta, no una continuació del que Fintonic era: Fintonic era B2C amb monetització per comparació de productes i comissions. El model que proposo és B2B2C.

El mercat rellevant no és "app de finances personals per a usuaris" —allà hi ha competència gratuïta i els usuaris no paguen— sinó el mercat d'eines de compromís financer per a entitats de mida mitjana.

• A Espanya hi ha desenes de cooperatives de crèdit, caixes rurals i bancs petits que competeixen amb BBVA, Santander i CaixaBank sense pressupost digital equivalent (estimació: 60-90 entitats rellevants, a validar amb registres del Banc d'Espanya).
• Aquestes entitats perden clients joves davant les apps de neobancs i necessiten funcionalitats de visió agregada que els seus core bancaris no ofereixen.
• El mercat europeu de "PFM as a service" existeix i té proveïdors, però la quota de penetració en entitats mitjanes és baixa (estimació qualitativa, a validar).

El senyal que dona el destí de Fintonic és ambigu i cal llegir-lo bé: BNP Paribas va comprar el producte, no el negoci d'usuari. Això suggereix que el valor estava en la tecnologia i l'equip, no en la base d'usuaris B2C. La lliçó de mercat és que el comprador natural d'aquesta capa és una entitat financera, no el consumidor.

Model B2B2C amb tres línies (totes són proposta):

1. Setup i integració: pagament únic per desplegar la capa blanca sobre el core de l'entitat. Rang estimat: 40.000-120.000 EUR per client, segons complexitat d'integració (a validar).
2. Llicència recurrent per usuari actiu: subscripció mensual per client actiu de l'entitat. Rang estimat: 0,30-1,00 EUR per usuari i mes (a validar; depèn del cost d'agregació i del marge objectiu).
3. Mòduls addicionals: scoring de crèdit responsable, simuladors d'estalvi, alertes predictives. Preu per mòdul, estimació 15.000-50.000 EUR anuals per entitat (a validar).

Marge brut objectiu: estimació del 55-70% un cop escalat, condicionat al cost real de les APIs d'agregació. Cal validar-ho amb contractes reals abans de modelar.

Fases (proposta, terminis estimats):

1. Mesos 0-3 — Validació: 10-15 entrevistes amb responsables de digital de cooperatives i bancs mitjans. Confirmar que pagarien i per quina funcionalitat exacta. No construir res encara.
2. Mesos 3-6 — Prototip sobre APIs existents: muntar la capa de categorització i visió agregada sobre un proveïdor d'agregació extern (no construir l'agregació pròpia; és on Fintonic va cremar recursos). Un o dos pilots amb entitats col·laboradores.
3. Mesos 6-12 — Primer contracte: tancar una entitat pilot amb setup pagat i llicència. Iterar el producte amb dades reals.
4. Mesos 12-24 — Repetició: 3-5 entitats clients. Aquí es valida si el model escala o si cada integració és un projecte a mida que mata el marge.

Punt crític: no començar pel consumidor. El camí B2C requereix capital de màrqueting que Fintonic va necessitar anys i inversió per sostenir.

Totes les xifres són estimacions a validar, no dades de Fintonic:

• Equip mínim (2-3 persones: producte, enginyeria, vendes tècniques) durant 12 mesos: 250.000-400.000 EUR.
• Cost d'APIs d'agregació en fase pilot: 10.000-30.000 EUR (depèn de volum).
• Legal, compliance i contractes B2B (RGPD, PSD2, acords amb entitats): 30.000-60.000 EUR.
• Infraestructura i eines: 15.000-30.000 EUR.
• Màrqueting B2B i venda (viatges, esdeveniments sectorials, material): 40.000-80.000 EUR.
• Coixí per a 6 mesos addicionals si el primer contracte triga: 100.000-200.000 EUR.

Total estimat per arribar a primer contracte: 400.000-900.000 EUR. Rang ampli perquè depèn de si l'equip és fundador o assalariat i de si la primera entitat paga setup o no.

1. Risc de commodity: si l'agregació i la categorització es commodititzen del tot, el marge desapareix i el producte es ven per preu. Mitigació: diferenciar-se en la capa de decisió (scoring, predicció), no en la de connexió.
2. Risc de cicle de venda llarg: vendre a bancs i cooperatives pot trigar 9-18 mesos per contracte (estimació). Sense coixí, el negoci mor abans del primer ingrés.
3. Risc de concentració: amb 3-5 clients, perdre'n un trenca el model. Cal diversificar ràpid o acceptar que és un negoci de nínxol.
4. Risc regulatori: PSD2 i les seves evolucions (PSD3, open finance) poden canviar les regles del joc i afavorir els bancs incumbents.
5. Risc de "fer-ho tot": el fracàs típic és voler ser producte B2C i B2B alhora. Fintonic va acabar venut perquè el B2C requereix capital que no es recupera fàcilment.

Les lliçons de l'informe original, no un currículum:

• Fintonic va demostrar que el producte tenia valor (algú va pagar per ell el 2021), però no que el negoci B2C fos sostenible de forma independent. La conclusió pràctica és que el valor estava en la tecnologia i l'equip, no en la relació directa amb l'usuari.
• L'agregació financera és infraestructura, no producte. Qui vulgui reconstruir-ho avui ha de vendre la infraestructura a qui la necessita, no competir per l'atenció del consumidor.
• El comprador natural és una entitat financera. Això defineix tot el model: preu, cicle de venda, equip i expectatives de creixement.
• Cal un equip que sàpiga vendre a bancs, no només construir producte. Aquesta és la diferència entre un projecte viable i un altre Fintonic que acaba absorbit.
• El capital necessari és modest si es va B2B (rang estimat 400.000-900.000 EUR) i enorme si es va B2C. L'elecció del model és l'elecció del risc.

En resum: el que es pot construir avui amb l'essència de Fintonic és una capa de salut financera venuda a entitats mitjanes, amb un cost de llançament estimat de 400.000-900.000 EUR i un risc principal que és comercial, no tecnològic.

Fintonic agregava informació de múltiples entitats financeres en una sola vista per ajudar l'usuari a entendre la seva situació econòmica. El problema real no era la visualització sinó la fragmentació: cada banc té el seu format, les seves dates de liquidació i les seves categories, i l'usuari no pot comparar ni detectar despeses anòmales sense reconciliar manualment extractes.

La font disponible ([Wikipedia] Fintonic — https://es.wikipedia.org/wiki/Fintonic) descriu el producte com una aplicació de finances personals amb agregació de comptes; aquesta especificació no assumeix detalls tècnics interns de l'empresa original, sinó que defineix una solució pròpia i implementable.

Arquitectura de microserveis amb un nucli d'ingesta i un servei de lectura separat, perquè la sincronització bancària és lenta i erràtica mentre que la consulta ha de ser ràpida.

``` [App mòbil / Web] | API Gateway (auth JWT, rate limit) | +-- Servei de Comptes (read model) +-- Servei de Categorització (regles + ML lleuger) +-- Servei d'Alertes (jobs) | Broker (Redis Streams) | +-- Ingesta PSD2 (connectors per banc) +-- Normalitzador de transaccions | Postgres (OLTP) + S3 (extractes crus) ```

Motius de les decisions:

• Postgres com a font de veritat: les transaccions financeres requereixen transaccionalitat i consultes per rang de dates; un document store complicaria la reconciliació.
• Read model separat: la categorització i els agregats es precalculen perquè la llista de moviments no faci joins costosos en cada obertura.
• Connectors aïllats per banc: cada entitat trenca el contracte PSD2 de manera diferent; aïllar-los permet desplegar correccions sense tocar el nucli.
• Extractes crus a S3: permeten reprocessar sense tornar a cridar el banc (cost i límits de rate).

Entitats principals (Postgres):

```sql users(id, email, created_at, kyc_status) consents(id, user_id, bank_id, scope, granted_at, expires_at, revoked_at) accounts(id, user_id, bank_id, external_id, iban_hash, currency, type) transactions(id, account_id, external_id, booked_at, amount_cents, currency, raw_description, normalized_merchant, category_id, ingest_batch_id, UNIQUE(account_id, external_id)) categories(id, parent_id, name, rules_json) alerts(id, user_id, type, threshold_cents, window_days, active) ingest_batches(id, bank_id, started_at, finished_at, status, error) ```

Decisions:

• `amount_cents` com a enter: evitar errors d'arrodoniment en agregacions.
• `iban_hash` en lloc d'IBAN en clar: minimitzar dades sensibles emmagatzemades.
• `UNIQUE(account_id, external_id)`: idempotència de la ingesta; els bancs repeteixen moviments.
• `raw_description` + `normalized_merchant` separats: permetre re-categoritzar sense perdre l'original.

• PSD2 / APIs bancàries obertes: consentiment per usuari i per compte, amb refresh de token abans de `expires_at`. Fallback a agregadors (p. ex. proveïdors AIS) per a bancs sense API estable.
• API interna REST (versionada `/v1`):

- `POST /v1/consents` — inicia consentiment, retorna URL del banc. - `GET /v1/accounts` — comptes de l'usuari autenticat. - `GET /v1/transactions?from=&to=&category=` — paginat per cursor. - `POST /v1/categories/rules` — regles de categorització de l'usuari. - `POST /v1/alerts` — llindars de despesa.

• Webhooks de consentiment: notificació de revocació per part del banc; el servei ha de marcar el consentiment i aturar la ingesta immediatament.
• Autenticació: OAuth2/OIDC per a usuaris, JWT de curta durada; mTLS entre serveis interns.

1. Connector d'un sol banc amb API PSD2 estable, per validar el flux de consentiment de punta a punta.
2. Normalitzador i taula `transactions` amb idempotència i reprocessament des de S3.
3. Read model de comptes i moviments amb paginació per cursor.
4. Categorització per regles (paraula clau → categoria), sense ML en la primera iteració.
5. Alertes de llindar sobre el read model.

Deixar per a després: ML de categorització, multi-banc massiu, informes financers avançats.

• Volum: un usuari actiu genera ~50-150 moviments/mes; 10k usuaris ≈ 1,5M files/mes. Postgres amb particionat per `booked_at` mensual és suficient fins a ordres de magnitud més grans.
• Latència d'ingesta: les APIs bancàries triguen segons; la ingesta ha de ser asíncrona i l'usuari ha de veure l'estat ("sincronitzant").
• Risc: inestabilitat de les APIs bancàries — mitigació: connectors aïllats, reintents amb backoff, circuit breaker per banc.
• Risc: duplicats i moviments pendents — mitigació: `external_id` + estat `pending/booked` i reconciliació posterior.
• Risc: compliment (RGPD, PSD2) — mitigació: minimitzar dades, hash d'IBAN, registre d'auditoria de consentiments i esborrat en revocació.
• Risc: categorització errònia — mitigació: regles de l'usuari prevalen sobre les automàtiques i es poden corregir.

• Test de contracte per connector: cada banc té un joc de respostes gravades; el connector ha de produir el mateix `transactions` normalitzat.
• Test d'idempotència: ingerir dues vegades el mateix lot no crea duplicats.
• Test de consentiment revocat: després del webhook de revocació, cap crida al banc i cap moviment nou.
• Mètriques d'acceptació: % de moviments categoritzats automàticament, temps mitjà de sincronització per banc, taxa d'errors per connector.
• Validació amb usuaris: comparar l'extracte del banc amb la vista de l'app per a una mostra de comptes; discrepàncies zero en imports i dates.