Phenix

Phenix Venture Sociedad Limitada era una societat limitada constituïda l'any 2014, amb domicili a Tarragona i activitat dins del sector dels serveis financers. El capital social registrat és de 138.530 euros. D'acord amb la fitxa registral consultada a OpenMercantil (a partir del BORME), la societat consta com a tancada.

La informació disponible no permet precisar quin producte o model de negoci concret oferia més enllà de la referència a una aplicació mòbil, esmentada per la font periodística.

La societat es va constituir l'any 2014 a Tarragona. Les dades disponibles no inclouen els noms dels socis fundadors ni les circumstàncies de la constitució, que no consten.

L'acte registral més antic de la cronologia facilitada és del 24 d'octubre de 2018: un nomenament d'apoderat a favor de Jessica Paola Olivares Tamayo, inscrit amb les dades registrals T 1971, F 20, S 8, H T 28712, I/A 3 (17.10.18), segons consta al BORME.

Segons Applicantes, Phenix operava mitjançant una aplicació mòbil adreçada al mercat espanyol. La font periodística es refereix al tancament de "la app de Phenix" a Espanya, cosa que situa l'activitat en l'àmbit dels serveis financers digitals.

Les dades disponibles no detallen el segment de clientela, el model d'ingressos ni l'abast geogràfic més enllà del mercat espanyol, i per tant aquests aspectes no consten.

No consta informació sobre l'evolució del negoci, el volum de clients, la facturació o les rondes de finançament. L'única dada registral intermèdia disponible és el nomenament d'apoderat del 2018. No es pot afirmar res sobre l'acompliment econòmic de l'empresa en cap període.

La causa del tancament no consta a les dades verificades. L'únic element documentat és la notícia d'Applicantes del 27 de març de 2025, que informa que l'aplicació de Phenix tancava les portes a Espanya. La fitxa registral posterior, d'acord amb el BORME, recull la situació de societat tancada.

No hi ha informació sobre si el tancament va ser una liquidació, una venda, una absorció o una altra operació societària, ni sobre les causes econòmiques o estratègiques.

No consta cap informació sobre la continuïtat del producte, la cessió de tecnologia o cartera de clients, ni sobre l'impacte del tancament en empleats o usuaris. Les dades disponibles no permeten descriure cap herència empresarial o tecnològica.

Els fundadors no consten a les dades disponibles. L'única persona identificada al corpus és Jessica Paola Olivares Tamayo, que hi apareix com a apoderada arran del nomenament inscrit el 2018, sense que es pugui afirmar que fos fundadora ni sàpiga quina és la seva situació actual.

Per completar aquesta informació es podrien consultar el Registre Mercantil de Tarragona (full registral H T 28712), les actes de la societat dipositades al registre i les notes de premsa posteriors al març de 2025.

• En una fintech que opera només amb aplicació mòbil, el tancament de l'app és el senyal visible del final: convé documentar per escrit, des del primer moment, si el tancament implica liquidació de la societat, cessió d'actius o simplement aturada del producte, perquè són situacions registrals molt diferents.
• Onze anys d'activitat amb un capital social de 138.530 euros i sense cap ampliació registrada a les dades disponibles suggereixen un creixement contingut; per a qualsevol anàlisi caldria verificar al registre si hi va haver aportacions o rondes no reflectides en la cronologia.
• La informació pública d'una fintech petita pot quedar reduïda a una notícia de tancament i una fitxa registral; per això és recomanable que les empreses del sector mantinguin actualitzada la informació del registre i de la seva comunicació corporativa.
• Per a qui avali projectes fintech a Catalunya, el cas recorda la importància de contrastar la dada registral de "tancada" amb la font periodística, atès que la primera no explica la causa i la segona no té valor registral.

El que sabem del cert és limitat: Phenix Venture SL era una startup de serveis financers a Tarragona, constituïda el 2014, amb un capital social de 138.530 EUR, i la seva aplicació va tancar a Espanya el març de 2025 [Applicantes, 2025-03-27]. La societat consta com a tancada al registre [BORME / BOE via OpenMercantil, 2025-05-05]. La causa del tancament no consta a les dades verificades.

Amb aquesta base, la proposta (no un fet) seria reconstruir l'essència —una fintech de proximitat, nascuda fora de Madrid i Barcelona, amb producte digital propi i una dècada d'experiència acumulada— com una aplicació de finances personals i serveis financers lleugers per a l'usuari particular i la petita empresa del territori. És una lectura raonable del sector i la ubicació, però cal validar-la amb l'equip fundador original abans de comprometre-hi res.

El mercat de serveis financers digitals a Espanya és gran i competitiu, i les dades verificades no ens diuen quina quota tenia Phenix ni quants usuaris va arribar a tenir. El que sí que podem afirmar és que una app fintech que va aguantar onze anys (2014-2025) va demostrar, com a mínim, capacitat de supervivència en un sector on la majoria de projectes moren abans. Això és un senyal, no una prova d'escala.

Proposta a validar: el nínxol més defensable per a un rellançament no és competir de front amb els grans neobancs, sinó ocupar el segment de proximitat —usuaris i pimes de les comarques de Tarragona i del Camp de Tarragona— amb un producte senzill, atenció propera i integració amb el teixit local. La mida d'aquest segment i la disposició a pagar s'han d'estimar amb dades reals abans de decidir res.

Proposta de model, a validar amb el mercat:

• Subscripció d'un pla bàsic gratuït i un de premium amb funcions avançades (estimació de preu: 3-8 EUR/mes, a validar).
• Comissions per serveis financers concrets (transferències, avançaments, productes d'estalvi) en col·laboració amb entitats regulades.
• Acords amb comerços i pimes locals per a serveis de cobrament o fidelització.

El punt crític: qualsevol activitat que impliqui captar fons o prestar serveis financers requereix autorització i supervisió reguladora (Banc d'Espanya / CNMV segons l'activitat). Això no és opcional i condiciona tot el model. La fórmula més lleugera és operar com a agent o col·laborador d'una entitat ja autoritzada, cosa que redueix molt el cost i el temps d'entrada.

Proposta en fases, amb terminis orientatius a validar:

1. Fase 0 — Recuperar el coneixement (1-2 mesos). Contactar l'equip i els socis originals de Phenix Venture SL per entendre què va funcionar, què va fallar i si hi ha actius reutilitzables (codi, marca, cartera). Aquesta fase és imprescindible i no es pot saltar.
2. Fase 1 — Validació de mercat (2-3 mesos). Entrevistes a usuaris i pimes del territori; dimensionar el nínxol; decidir el model regulatori (agent vs. llicència pròpia).
3. Fase 2 — Producte mínim (3-6 mesos). MVP sobre una plataforma d'entitat col·laboradora; marca i compliment normatiu.
4. Fase 3 — Llançament local i mesura (6-12 mesos). Captació a Tarragona i comarques, mètriques de retenció i cost d'adquisició.

Totes les xifres són estimacions orientatives i cal validar-les amb pressupostos reals. No tenim dades verificades del cost original de Phenix.

| Concepte | Rang estimat (a validar) | |---|---| | Constitució, legal i compliment normatiu | 8.000 – 25.000 EUR | | Producte / MVP (desenvolupament o llicència) | 30.000 – 90.000 EUR | | Màrqueting i captació inicial (12 mesos) | 20.000 – 60.000 EUR | | Equip mínim (2-4 persones, 12 mesos) | 80.000 – 180.000 EUR | | Contingència i operació | 15.000 – 40.000 EUR | | Total orientatiu any 1 | ~150.000 – 400.000 EUR |

Com a referència, el capital social original de Phenix va ser de 138.530 EUR [BORME / BOE via OpenMercantil, 2025-05-05]; un rellançament avui probablement necessitaria més que aquesta xifra per cobrir un any d'operació, però això és una estimació, no un fet.

• Regulatori: sense autorització o acord amb entitat supervisada, el projecte no pot operar. És el risc número u.
• Causa de tancament desconeguda: no consta per què va tancar Phenix [dades verificades]. Sense saber-ho, es pot repetir el mateix error. Cal esbrinar-ho abans de res.
• Competència: el sector fintech espanyol és molt disputat; un projecte local ha de tenir un avantatge clar.
• Capital: els rangs de cost són amplis i la captació de finançament en fintech és exigent.
• Marca cremada: rellançar el nom "Phenix" després d'un tancament pot generar desconfiança; potser convé una marca nova amb la mateixa essència.

Les lliçons que es desprenen de l'expedient original:

1. Once anys no són un fracàs, però no garanteixen res. Phenix va sobreviure onze anys i tot i així va tancar; la longevitat sense model sostenible no salva un projecte.
2. El capital inicial no és el problema principal. Amb 138.530 EUR de capital social va arrencar; el repte és el model i el compliment normatiu, no la xifra de sortida.
3. La informació és el primer actiu. La causa del tancament no consta: qui vulgui reconstruir-ho ha de començar per recuperar el coneixement de l'equip original, no per aixecar diners.
4. L'essència local és un actiu, no una limitació. Una fintech de Tarragona pot competir per proximitat i confiança on els grans no arriben.
5. Validar abans de construir. Totes les xifres d'aquest informe són estimacions; el primer pas real és parlar amb qui ho va viure i mesurar el mercat amb dades, no amb entusiasme.

Una app financera de consum com la que va operar Phenix Venture SL fins al 2025 necessita cobrar de manera recurrent, gestionar altes i baixes de subscripció, conciliar els cobraments amb el proveïdor de pagaments i complir amb la normativa de serveis de pagament. Sense una plataforma pròpia, aquestes funcions queden repartides entre el PSP (proveïdor de serveis de pagament), fulls de càlcul i el backend de producte, cosa que genera errors de conciliació, baixes no aplicades i impossibilitat d'auditar ingressos.

El problema concret que resol aquesta especificació és: un únic servei de subscripcions i cobraments recurrents, amb estat auditable i conciliació diària contra el PSP, que el producte pugui consumir via API i que l'equip financer pugui tancar mensualment sense intervenció manual.

Arquitectura de microserveis moderada, amb un nucli transaccional i serveis satèl·lit. El motiu és que el domini de cobrament recurrent requereix consistència forta en l'estat de la subscripció, mentre que les notificacions i la conciliació poden ser asíncrones.

Components:

``` [App mòbil / Web] --HTTPS--> [API Gateway] | +-------------+--------------+ | | [subscription-core] [billing-worker] (PostgreSQL, escriptures) (cues, reintents) | | +----------> [outbox] <------+ | [reconciliation-service] | [PSP adapter: Stripe/Adyen] ```

• subscription-core: servei síncron amb PostgreSQL. Gestiona l'estat de la subscripció (alta, canvi de pla, baixa, pausa). Motiu: és el punt on no es pot tolerar inconsistència.
• billing-worker: consumeix cues per executar cobraments, reintents i enviaments d'esdeveniments. Motiu: els reintents no han de bloquejar l'API.
• outbox: patró transactional outbox a la mateixa base de dades del core. Motiu: garantir que cap esdeveniment de cobrament es perd entre la transacció i la cua.
• reconciliation-service: job diari que compara els càrrecs interns amb els del PSP. Motiu: detectar desquadraments abans del tancament comptable.
• PSP adapter: capa d'abstracció sobre Stripe o Adyen. Motiu: evitar acoblament al proveïdor i permetre canviar-lo.

Desplegament en contenidors (ECS o Kubernetes) amb PostgreSQL gestionat i cua SQS o equivalent. No s'usa event sourcing complet: el cost de complexitat no es justifica per a l'abast inicial.

Esquema relacional a PostgreSQL. Taules principals:

```sql customer(id uuid pk, external_ref text, email text, country char(2), tax_id text null, created_at timestamptz)

plan(id uuid pk, code text unique, amount_cents int, currency char(3), interval_unit text, interval_count int, trial_days int, active boolean, version int)

subscription(id uuid pk, customer_id uuid fk, plan_id uuid fk, status text, -- active|past_due|canceled|paused current_period_start timestamptz, current_period_end timestamptz, cancel_at_period_end boolean, psp_subscription_ref text, created_at timestamptz, updated_at timestamptz)

invoice(id uuid pk, subscription_id uuid fk, amount_cents int, currency char(3), status text, -- open|paid|failed|refunded period_start timestamptz, period_end timestamptz, psp_charge_ref text null, created_at timestamptz)

payment_attempt(id uuid pk, invoice_id uuid fk, attempt_no int, status text, error_code text null, psp_response jsonb, attempted_at timestamptz)

outbox_event(id bigserial pk, aggregate_id uuid, event_type text, payload jsonb, published_at timestamptz null, created_at timestamptz)

reconciliation_run(id uuid pk, run_date date, matched int, unmatched int, status text, finished_at timestamptz) ```

Decisions i motius:

• `amount_cents` en enter: evitar errors d'arrodoniment en coma flotant.
• `plan.version`: els canvis de preu no alteren subscripcions existents; es crea una versió nova del pla.
• `invoice` separada de `payment_attempt`: una factura pot tenir diversos intents de cobrament.
• `outbox_event`: garanteix lliurament almenys un cop cap a la cua.

API REST versionada (`/v1`) amb autenticació per token d'equip i per usuari final (OAuth2). Endpoints principals:

• `POST /v1/subscriptions` — alta; retorna `subscription_id` i estat.
• `PATCH /v1/subscriptions/{id}` — canvi de pla o `cancel_at_period_end`.
• `DELETE /v1/subscriptions/{id}` — baixa immediata o al final del període.
• `GET /v1/invoices?subscription_id=` — llistat de factures i intents.
• `POST /v1/webhooks/psp` — recepció d'esdeveniments del PSP, verificats per signatura HMAC.

Integracions:

• PSP (Stripe/Adyen): cobraments, tokens de targeta, webhooks de `payment_succeeded` i `payment_failed`. Motiu: delegar el compliment PCI-DSS al PSP.
• Motor de correu transaccional: rebuts i avisos de fallada de cobrament.
• Sistema comptable: exportació mensual de factures en CSV o API, per al tancament.

Idempotència obligatòria: cada crida de cobrament porta una clau `Idempotency-Key` derivada de `invoice_id` i `attempt_no`.

Fase 1 (MVP, 6–8 setmanes):

1. `subscription-core` amb taules `customer`, `plan`, `subscription` i alta/baixa.
2. Integració amb un sol PSP i cobrament del primer període.
3. Outbox i `billing-worker` amb reintents bàsics (3 intents, backoff exponencial).
4. Webhook de PSP amb verificació de signatura.

Fase 2:

1. `invoice` i `payment_attempt` amb historial complet.
2. `reconciliation-service` diari.
3. Exportació comptable.

Motiu de l'ordre: sense alta, cobrament i webhook no hi ha producte; la conciliació i l'exportació són necessàries per operar, però no per validar el flux principal.

Mides estimades per al MVP:

• 3 serveis desplegables, 1 base de dades PostgreSQL, 1 cua.
• Volum esperat: 10.000–100.000 subscripcions actives; 1–5 cobraments per segon en pics.
• Emmagatzematge: < 50 GB anuals amb historial de factures.

Riscos:

• Doble cobrament per reintents i webhooks duplicats: mitigat amb idempotència i outbox.
• Desquadra PSP vs intern per desfases horaris: mitigat amb conciliació per `psp_charge_ref` i no per data.
• Canvi de PSP: mitigat per l'adapter; risc residual en la migració de tokens de targeta.
• Compliment PSD2/SCA: els cobraments recurrents requereixen autenticació reforçada en alguns casos; cal coordinar amb el PSP.
• Dependència d'un sol proveïdor: risc operatiu; es documenta pla de sortida.

• Tests d'integració contra l'entorn sandbox del PSP per a alta, cobrament, fallada i reintent.
• Tests de conciliació: joc de dades amb càrrecs coincidents i no coincidents; el servei ha de reportar exactament els desquadraments.
• Test d'idempotència: enviar el mateix webhook i la mateixa clau de cobrament diverses vegades; no s'ha de generar cap càrrec duplicat.
• Càrrega: 5 cobraments/segon sostinguts durant 1 hora sense pèrdua d'esdeveniments a l'outbox.
• Criteri d'acceptació del MVP: una subscripció d'alta, cobrament del primer període, fallada simulada, reintent exitós i factura en estat `paid`, tot auditable a la base de dades.

Fonts consultades per al context de l'empresa: [Applicantes, 2025-03-27], [BORME / BOE (via OpenMercantil), 2025-05-05], [BOE / BORME, 2025-05-05].