Phenix

Phenix Venture Sociedad Limitada era una sociedad limitada constituida en 2014, con domicilio en Tarragona y actividad dentro del sector de los servicios financieros. El capital social registrado es de 138.530 euros. De acuerdo con la ficha registral consultada en OpenMercantil (a partir del BORME), la sociedad consta como cerrada.

La información disponible no permite precisar qué producto o modelo de negocio concreto ofrecía más allá de la referencia a una aplicación móvil, mencionada por la fuente periodística.

La sociedad se constituyó en 2014 en Tarragona. Los datos disponibles no incluyen los nombres de los socios fundadores ni las circunstancias de la constitución, que no constan.

El acto registral más antiguo de la cronología facilitada es del 24 de octubre de 2018: un nombramiento de apoderado a favor de Jessica Paola Olivares Tamayo, inscrito con los datos registrales T 1971, F 20, S 8, H T 28712, I/A 3 (17.10.18), según consta en el BORME.

Según Applicantes, Phenix operaba mediante una aplicación móvil dirigida al mercado español. La fuente periodística se refiere al cierre de "la app de Phenix" en España, lo que sitúa la actividad en el ámbito de los servicios financieros digitales.

Los datos disponibles no detallan el segmento de clientela, el modelo de ingresos ni el alcance geográfico más allá del mercado español, y por tanto estos aspectos no constan.

No consta información sobre la evolución del negocio, el volumen de clientes, la facturación o las rondas de financiación. El único dato registral intermedio disponible es el nombramiento de apoderado de 2018. No se puede afirmar nada sobre el desempeño económico de la empresa en ningún periodo.

La causa del cierre no consta en los datos verificados. El único elemento documentado es la noticia de Applicantes del 27 de marzo de 2025, que informa de que la aplicación de Phenix cerraba sus puertas en España. La ficha registral posterior, de acuerdo con el BORME, recoge la situación de sociedad cerrada.

No hay información sobre si el cierre fue una liquidación, una venta, una absorción u otra operación societaria, ni sobre las causas económicas o estratégicas.

No consta ninguna información sobre la continuidad del producto, la cesión de tecnología o cartera de clientes, ni sobre el impacto del cierre en empleados o usuarios. Los datos disponibles no permiten describir ninguna herencia empresarial o tecnológica.

Los fundadores no constan en los datos disponibles. La única persona identificada en el corpus es Jessica Paola Olivares Tamayo, que aparece como apoderada a raíz del nombramiento inscrito en 2018, sin que se pueda afirmar que fuera fundadora ni se sepa cuál es su situación actual.

Para completar esta información se podrían consultar el Registro Mercantil de Tarragona (folio registral H T 28712), las actas de la sociedad depositadas en el registro y las notas de prensa posteriores a marzo de 2025.

• En una fintech que opera solo con aplicación móvil, el cierre de la app es la señal visible del final: conviene documentar por escrito, desde el primer momento, si el cierre implica liquidación de la sociedad, cesión de activos o simplemente parada del producto, porque son situaciones registrales muy diferentes.
• Once años de actividad con un capital social de 138.530 euros y sin ninguna ampliación registrada en los datos disponibles sugieren un crecimiento contenido; para cualquier análisis habría que verificar en el registro si hubo aportaciones o rondas no reflejadas en la cronología.
• La información pública de una fintech pequeña puede quedar reducida a una noticia de cierre y una ficha registral; por eso es recomendable que las empresas del sector mantengan actualizada la información del registro y de su comunicación corporativa.
• Para quien evalúe proyectos fintech en Cataluña, el caso recuerda la importancia de contrastar el dato registral de "cerrada" con la fuente periodística, dado que la primera no explica la causa y la segunda no tiene valor registral.

El que sabem del cert és limitat: Phenix Venture SL va ser una societat de serveis financers amb seu a Tarragona, constituïda el 2014, amb un capital social de 138.530 EUR, i que el març de 2025 va veure com la seva aplicació tancava portes a Espanya ([Applicantes, 2025-03-27]). El registre mercantil la mostra com a tancada ([BORME/OpenMercantil, 2025-05-05]) i no consta la causa del tancament.

Això vol dir que no podem afirmar amb verificació quin era exactament el producte de Phenix ni per què va fracassar. Qualsevol reconstrucció ha de partir d'aquesta humilitat: no copiem un model que no coneixem en detall, sinó que proposem un projecte nou que ocupi un espai adjacent i versemblant.

Proposta (no verificada): reconstruir l'essència "finances digitals accessibles des d'una ciutat mitjana" com una app de gestió financera personal i estalvi automatitzat per a usuaris particulars i petits autònoms, amb una capa de servei local (assessorament bàsic, educació financera) que diferenciï el producte de les grans apps nacionals. L'essència que es preserva és la categoria (fintech de proximitat), no el producte concret.

El mercat de finances personals digitals a Espanya és gran i competitiu: hi ha bancs digitals, apps d'agregació i gestors d'estalvi. La mort de Phenix no és evidència que el mercat no existeixi, sinó que l'execució i el model de negoci són difícils en un sector amb cost d'adquisició d'usuari alt i monetització fràgil.

Estimació (a validar): l'oportunitat més realista per a un projecte petit no és competir frontalment amb les grans apps, sinó atendre nínxols mal servits: autònoms i microempreses de comarques fora de Barcelona, usuaris poc bancaritzats digitalment i col·lectius que volen educació financera acompanyada. Aquestes afirmacions de mercat són hipòtesis de treball, no dades verificades.

Proposta (a validar): un model mixt amb tres fonts d'ingrés:

1. Subscripció a la versió premium de l'app (gestió, alertes, pressupostos).
2. Comissió o quota per serveis d'assessorament bàsic (sessions, plans d'estalvi), possiblement en col·laboració amb professionals habilitats segons correspongui.
3. Acords B2B amb gremis, cooperatives o ajuntaments per oferir el servei als seus associats.

La clau és no dependre d'una sola font. El tancament de Phenix recorda que la monetització d'una app financera és el punt feble habitual.

Proposta (a validar), en fases:

• Fase 0 (mesos 1-2): validació. Entrevistes amb 30-50 usuaris objectiu (autònoms, estalviadors), definició de l'MVP i verificació del marc regulatori aplicable (protecció de dades, i si hi ha serveis financers regulats, llicències o partenariat amb entitat habilitada).
• Fase 1 (mesos 3-6): MVP de l'app de gestió i estalvi, amb un pilot tancat a Tarragona i comarques.
• Fase 2 (mesos 7-12): obertura progressiva, primers ingressos per subscripció i acords B2B.
• Fase 3 (any 2): avaluació de mètriques (retenció, cost d'adquisició, ingrés per usuari) i decisió de créixer o pivotar.

Estimació (rang a validar, no és cap dada de Phenix):

• Equip fundador i desenvolupament MVP: 60.000-120.000 EUR el primer any (2-3 persones, part externa).
• Compliment normatiu i legal (RGPD, termes, possible assessoria financera): 10.000-25.000 EUR.
• Màrqueting i adquisició inicial: 15.000-40.000 EUR.
• Operació i infraestructura: 10.000-20.000 EUR.

Total orientatiu any 1: 95.000-205.000 EUR, a validar amb pressupostos reals. El capital social de Phenix (138.530 EUR) cau dins d'aquest rang, però no implica que fos el seu cost real de funcionament.

• Regulatori: els serveis financers estan sotmesos a normativa estricta; cal verificar què es pot oferir sense llicència i què requereix partenariat.
• Adquisició d'usuaris: cost alt i competència de grans actors; és el risc que probablement va pesar en el sector.
• Monetització: convertir usuaris en ingressos recurrents és difícil; cal validar-ho abans d'escalar.
• Causa de tancament desconeguda: com que no consta per què va tancar Phenix, no podem descartar que fos per factors que també afectarien un projecte nou.
• Concentració geogràfica: un projecte de proximitat pot tenir sostre de mercat limitat.

Les lliçons de l'informe original, més enllà del cas concret, són:

1. No idealitzar el model original: sense conèixer la causa del tancament, cal reconstruir amb hipòtesis explícites i validar-les.
2. La monetització és el coll d'ampolla: una app financera sense model d'ingrés clar no se sosté, per bona que sigui la idea.
3. El marc regulatori no és opcional: en finances, el compliment és part del producte.
4. L'avantatge local és real però limitat: Tarragona i el territori donen proximitat i confiança, però cal un pla per créixer més enllà.
5. Qui ho hauria de fer: un equip fundador amb experiència en producte digital i en compliment financer, arrelat al territori, disposat a validar abans d'invertir i a pivotar si les mètriques no acompanyen. No un currículum brillant, sinó algú que accepti que la incertesa és el punt de partida.

El tancament de Phenix deixa usuaris d'apps de finances personals a l'Estat sense un servei equivalent i, sobretot, sense exportació neta de les seves dades [Applicantes, 2025-03-27]. El problema tècnic concret és doble: (1) agregar saldos i moviments de múltiples bancs espanyols de forma fiable i idempotent, i (2) convertir moviments en brut en categories i pressupostos útils sense exigir a l'usuari una feina manual excessiva.

La causa del tancament no consta al registre [BORME / BOE (via OpenMercantil), 2025-05-05], de manera que no es pot atribuir a un únic factor; el disseny ha de reduir costos variables (agregació, inferència) i evitar dependència d'un sol proveïdor.

Arquitectura de serveis amb un backend modular monolític (monòlit modular) desplegat en contenidors, perquè l'equip inicial és petit i la latència de xarxa interna no és el coll d'ampolla. Motiu: menys sobrecost operatiu que microserveis, i permet extreure mòduls quan calgui.

Components:

• API Gateway (autenticació JWT, rate limiting per usuari i per IP).
• Mòdul d'identitat: gestió d'usuaris, sessions i consentiments PSD2 amb caducitat.
• Mòdul d'agregació: connector amb proveïdor AISP (PSD2), cua de sincronització i conciliació.
• Mòdul de domini financer: comptes, transaccions, categories, pressupostos.
• Motor de categorització: regles deterministes + classificador estadístic amb fallback.
• Mòdul de notificacions: alertes de pressupost i de nous moviments.
• Magatzem analític separat (només lectura) per a mètriques agregades i anonimitzades.

Flux de sincronització (descripció en text): ``` [App mòbil] --HTTPS--> [API Gateway] --> [Agregació] [Agregació] --encua--> [Cua de sincronització] [Worker] --consulta AISP--> [Banc via PSD2] [Worker] --upsert idempotent--> [PostgreSQL: transaccions] [Worker] --event--> [Motor de categorització] --> [Notificacions] ```

Decisions i motius:

• PostgreSQL com a base principal: transaccions financeres requereixen transaccionalitat i restriccions d'unicitat per garantir idempotència.
• Cua de missatges (Redis Streams o equivalent) per desacoblar la sincronització bancària de la petició de l'usuari i permetre reintents amb backoff.
• Clau d'idempotència per moviment: `(compte_id, external_id)` únic, perquè els proveïdors AISP poden repetir moviments entre sincronitzacions.

Esquema relacional principal (PostgreSQL). Noms en anglès per coherència amb l'ecosistema.

```sql users(id UUID PK, email CITEXT UNIQUE, created_at TIMESTAMPTZ) consents(id UUID PK, user_id UUID FK, provider TEXT, scope TEXT, granted_at TIMESTAMPTZ, expires_at TIMESTAMPTZ, revoked_at TIMESTAMPTZ NULL) accounts(id UUID PK, user_id UUID FK, iban_hash TEXT, bank_code TEXT, currency CHAR(3), balance NUMERIC(14,2), last_synced_at TIMESTAMPTZ, UNIQUE(user_id, iban_hash)) transactions(id UUID PK, account_id UUID FK, external_id TEXT, amount NUMERIC(14,2), currency CHAR(3), booked_at TIMESTAMPTZ, description TEXT, category_id UUID FK NULL, category_source TEXT, UNIQUE(account_id, external_id)) categories(id UUID PK, user_id UUID NULL, name TEXT, parent_id UUID NULL) rules(id UUID PK, user_id UUID FK, match_type TEXT, pattern TEXT, category_id UUID FK, priority INT) budgets(id UUID PK, user_id UUID FK, category_id UUID FK, period TEXT, limit_amount NUMERIC(14,2)) ```

Motius:

• `iban_hash` en lloc d'IBAN en clar: minimitza dades sensibles i compleix minimització de dades.
• `category_source` (`rule`, `model`, `user`) permet auditar per què un moviment té una categoria i mesurar la qualitat del model.
• `UNIQUE(account_id, external_id)` és la garantia d'idempotència esmentada.

API REST versionada (`/v1`) amb OpenAPI 3.1 com a contracte. Autenticació Bearer JWT; consentiments PSD2 gestionats pel mòdul d'identitat.

Endpoints principals:

• `POST /v1/consents` — inicia consentiment amb el proveïdor AISP.
• `GET /v1/accounts` — llista comptes i saldos.
• `GET /v1/transactions?from=&to=&category=` — moviments paginats per cursor.
• `POST /v1/transactions/{id}/category` — correcció manual de categoria.
• `POST /v1/budgets` i `GET /v1/budgets/status` — pressupostos i estat.
• `POST /v1/sync` — força sincronització (rate-limited).

Integracions:

• Proveïdor AISP PSD2 (agregació bancària): única dependència externa crítica. Motiu per aïllar-lo en un mòdul amb interfície pròpia: permetre canviar de proveïdor sense tocar el domini.
• Passarel·la de notificacions push (APNs/FCM).
• Webhooks interns per a esdeveniments de sincronització i alertes.

1. Mòdul d'identitat i consentiments amb caducitat i revocació: sense consentiment vàlid no hi ha accés a dades bancàries.
2. Connector AISP + conciliació idempotent de comptes i moviments: és el nucli de valor i el punt de risc més alt.
3. Llistat de moviments i saldos amb paginació per cursor.
4. Regles de categorització deterministes (prioritat sobre model) i correcció manual.
5. Pressupostos i alertes bàsiques.

El model estadístic de categorització s'ajorna a la fase 2: primer cal volum real de moviments i correccions per entrenar-lo.

Mides orientatives per a un MVP:

• 1 proveïdor AISP, 3–5 bancs espanyols coberts.
• Fins a ~50.000 usuaris actius; ~2–5 milions de transaccions/mes.
• Sincronització diària per compte + sincronització sota demanda amb límit (p. ex. 1 cada 6 hores per usuari).

Riscos:

• Disponibilitat i límits del proveïdor AISP: reintents amb backoff, circuit breaker i estat de sincronització visible a l'usuari.
• Duplicats de moviments: mitigat per la clau única i upsert idempotent.
• Qualitat de categorització: risc de confiança baixa; mitigat amb `category_source` i correcció fàcil.
• Compliment i privacitat: dades financeres sensibles; cal xifrat en repòs, minimització i política de retenció.
• Cost variable d'agregació: controlar freqüència de sincronització per usuari.

• Tests de conciliació: conjunts de fixtures amb moviments repetits, desordenats i amb imports negatius; s'ha de verificar que el recompte final és estable (idempotència).
• Tests de contracte de l'API contra l'OpenAPI 3.1.
• Pilot tancat amb usuaris reals i un banc per mesurar: taxa de conciliació, temps de sincronització i percentatge de moviments categoritzats automàticament.
• Mètriques d'èxit del pilot: >95% de moviments conciliats sense duplicats, >70% categoritzats automàticament, i correcció manual en <2 tocs.
• Auditoria de consentiments: cap accés a dades sense consentiment vigent; proves de revocació i caducitat.

Referències: [Applicantes, 2025-03-27]; [BORME / BOE (via OpenMercantil), 2025-05-05]; [BOE / BORME, 2025-05-05].