Verse

Verse era una startup del sector fintech que operava en l'àmbit dels pagaments entre particulars. Segons Cinco Días, se la presentava com a competidora de Bizum. La ubicació de l'empresa no consta a les dades disponibles.

No consta a les dades disponibles cap informació sobre la data de fundació, els fundadors ni les circumstàncies en què es va crear l'empresa.

Verse oferia serveis de pagament entre particulars, és a dir, transferències de diners entre usuaris, en un segment dominat per Bizum. Segons Cinco Días, l'empresa tenia dos milions de clients en el moment del tancament. No consta a les dades disponibles cap detall addicional sobre el model de negoci, les comissions o els productes concrets que oferia.

No consta a les dades disponibles informació sobre l'evolució del negoci, el creixement, la facturació o les rondes de finançament de l'empresa. L'única dada sobre la seva dimensió és la xifra de dos milions de clients que recull Cinco Días en la notícia del tancament.

El 13 de juliol de 2023, segons Cinco Días, Verse va anunciar el seu tancament i va demanar als seus dos milions de clients que retiressin els diners dels comptes. La causa del tancament no consta a les dades disponibles: la font periodística citada recull l'anunci i la petició de retirada de fons, però no una explicació verificada dels motius.

No consta a les dades disponibles informació sobre el destí dels actius, la cartera de clients, la tecnologia o la marca de l'empresa després del tancament.

No consta a les dades disponibles la identitat dels fundadors ni la seva trajectòria posterior. Per traçar-la, es podria consultar el registre mercantil corresponent a la societat, les notes de premsa de l'empresa i les fonts periodístiques especialitzades en fintech que hagin seguit el sector.

• En un mercat de pagaments entre particulars dominat per un operador amb efecte de xarxa (Bizum), la dimensió de la base d'usuaris no garanteix per si sola la viabilitat: Verse tenia dos milions de clients i va tancar igualment, segons Cinco Días.
• La retirada ordenada de fons dels clients és una operació crítica en el tancament d'una fintech de pagaments; el cas mostra la necessitat de planificar la comunicació i el retorn de saldos amb antelació.
• La manca de dades públiques verificades sobre la causa del tancament limita l'aprenentatge: per a futures anàlisis caldria disposar de la informació registral i financera de la societat, que en aquest cas no consta.

Verse era una aplicació de pagaments entre particulars que competia frontalment amb Bizum. L'únic fet sòlid que tenim és el seu final: el 13 de juliol de 2023 va anunciar el tancament i va demanar als seus dos milions de clients que traguessin els diners de la plataforma (Cinco Días, 2023-07-13). No consta la causa, i per tant qualsevol explicació del fracàs és una hipòtesi.

La idea reconstruïble avui no és "un Bizum millor". És una capa de pagaments P2P i de petit comerç que no custodi diners dels usuaris: saldos en una entitat de pagament o banc col·laborador, liquidació instantània via SEPA Instant, i una experiència mòbil centrada en el que Verse feia bé — pagaments entre persones sense fricció. La diferència estructural respecte al 2020-2023 és que avui no cal construir un banc per fer pagaments: es lloga.

Això és una proposta, no una continuació de Verse. Verse està tancada i no hi ha cap indici que es pugui reprendre la marca o la cartera de clients.

El mercat rellevant és el de pagaments P2P i de proximitat a Espanya i, si s'escau, a la zona euro. La dada verificada més útil és la mida de la base d'usuaris que Verse va arribar a tenir: dos milions de clients en el moment del tancament (Cinco Días, 2023-07-13). Això demostra que hi havia demanda d'ús, no que hi hagués disposició a pagar.

El que no sabem i no podem afirmar: quants d'aquells dos milions eren actius, quin volum movien, quina rendibilitat per usuari hi havia, ni per què el producte no va sostenir-se. Cap d'aquestes dades consta a les fonts disponibles.

Com a estimació a validar: el mercat de pagaments P2P a Espanya està dominat per Bizum, integrat a la banca tradicional, i un entrant nou ha de competir en nínxols on Bizum és feble — per exemple, pagaments entre usuaris de països diferents de la zona euro, o col·lectius que no volen vincular el compte bancari principal. Aquest és un judici de mercat, no una dada verificada.

Proposta, amb xifres a validar:

• Ingressos per comissió intercanvi (interchange) en pagaments a comerços, no en P2P entre particulars.
• Subscripció premium per a usuaris intensius o per a funcions de compte compartit (despeses de pis, viatges de grup).
• Comissió per transferències transfrontereres dins la zona euro, on el cost per a l'usuari encara és percebut com a alt.
• Possible acord de marca blanca amb una entitat de pagament o banc que aporti la llicència i la custòdia.

El que no es pot replicar del model de Verse és la seva estructura de costos, perquè no consta. Qualsevol afirmació sobre el seu burn rate o la seva unit economics seria inventada.

Fases, amb terminis estimats i a validar:

1. Mesos 0-3 — Validació. Entrevistes amb usuaris que haguessin fet servir Verse (si es poden localitzar) i amb col·lectius objectiu. Definició del nínxol. Cap desenvolupament de producte.
2. Mesos 3-9 — Construcció sobre infraestructura existent. Contracte amb un proveïdor de pagaments amb llicència (entitat de pagament o banc col·laborador), integració de SEPA Instant, aplicació mòbil mínima. Objectiu: P2P funcional en un sol mercat.
3. Mesos 9-15 — Pilot tancat. Un o dos col·lectius concrets, mètrica d'activació i recurrència. Aquí es decideix si el producte té sentit o no.
4. Mesos 15-24 — Obertura i comerç. Afegir pagaments a comerços, que és on hi ha marge. Sense aquesta pota, el negoci no paga les factures.

La lliçó del calendari de Verse, pel que es pot inferir del fet del tancament el 2023, és que créixer en usuaris sense monetitzar-los no sosté l'operació. Això és inferència, no dada verificada.

Tot són estimacions a validar, en cap cas xifres contrastades:

• Equip mínim (3-5 persones: producte, enginyeria, compliance, negoci): rang de 400.000-700.000 € anuals de cost laboral a Espanya, estimació.
• Infraestructura i llicència indirecta via proveïdor de pagaments: rang de 50.000-150.000 € anuals en funció del volum, estimació.
• Desenvolupament i integració inicial: rang de 150.000-300.000 €, estimació.
• Legal, compliance i KYC/AML: rang de 40.000-100.000 € el primer any, estimació.
• Màrqueting de llançament: molt variable; rang de 100.000-300.000 € per a un pilot amb ambició, estimació.

Ordre de magnitud total per als primers 18 mesos: entre 1 i 2 milions d'euros, estimació a validar amb proveïdors i amb un pla financer real. No és una xifra que es pugui presentar a un inversor sense treballar-la.

• Risc de causa desconeguda. No sabem per què va tancar Verse. Reconstruir sense saber què va fallar és el risc principal: es pot repetir l'error sense veure'l. Això és el més important d'aquest informe.
• Risc de competidor dominant. Bizum és a la banca i té efecte de xarxa. Un entrant ha de triar un nínxol on aquest efecte no arribi.
• Risc regulatori. Els pagaments requereixen llicència o un soci amb llicència; el compliment KYC/AML és cost fix i creixent.
• Risc de custòdia. Si es custodien fons de clients, l'exigència de capital i de governança puja molt. La proposta d'aquest informe evita la custòdia precisament per això.
• Risc de marca. "Verse" està associada a un tancament amb petició de retirada de diners. Reutilitzar el nom seria un passiu, no un actiu.

Aquest informe no és un currículum ni una recomanació de persones. El que es pot extreure de la informació verificada és això:

• Lliçó 1: dos milions d'usuaris no són un negoci. Verse va arribar a una base d'usuaris gran i va tancar igualment (Cinco Días, 2023-07-13). Qui vulgui reconstruir-ho ha de començar pel model d'ingressos, no per la captació.
• Lliçó 2: el tancament es va comunicar demanant treure els diners. Això indica que la confiança de l'usuari és el actiu més fràgil del sector. Qualsevol projecte nou ha de néixer amb custòdia separada i comunicació radicalment transparent.
• Lliçó 3: no consta la causa. La lliçó metodològica és que qui vulgui fer això ha de reconstruir la història de Verse amb dades reals abans de gastar un euro. Aquest informe no les té i no les inventa.

Per tant, ho hauria de fer un equip que (a) accepti començar per un nínxol petit i monetitzable, (b) no necessiti custodiar diners per operar, i (c) tingui un soci amb llicència de pagament des del dia u. La resta és proposta, no conclusió verificada.

Verse era un competidor de Bizum que va anunciar el seu tancament el juliol de 2023 i va demanar als seus dos milions de clients que retiressin els diners del compte [Cinco Días, 2023-07-13]. El problema tècnic que això exposa no és tant fer pagaments P2P com garantir que els saldos dels usuaris siguin sempre accessibles, auditables i exportables, fins i tot quan el producte deixa d'operar.

La solució que descric és un servei de pagaments entre particulars amb compte de diners electrònic, on cada cèntim té un assentament immutable i on la retirada de fons és una operació de primera classe, no una funcionalitat afegida al final. El motiu és directe: en una fintech de pagaments, el risc principal no és que falli un pagament, sinó que falli la confiança en el saldo.

Tres serveis i un magatzem de dades, amb comunicació asíncrona per a tot el que toca diners:

``` [App mòbil] --HTTPS--> [API Gateway] | +-------------+-------------+ | | | [payments-svc] [ledger-svc] [payout-svc] | | | +------> [Kafka] <----------+ | [PostgreSQL ledger] | [bank-adapter] ```

• ledger-svc: font de veritat dels saldos. Només accepta escriptures en forma d'assentaments dobles (dèbit i crèdit que sumen zero). Motiu: un saldo calculat per suma d'assentaments és auditable i reconstruïble; un camp `balance` mutable no ho és.
• payments-svc: orquestra transferències P2P. No toca saldos directament; publica comandes al ledger i espera confirmació.
• payout-svc: gestiona la retirada de fons cap al compte bancari de l'usuari. És el servei crític en un escenari de tancament, i per això té prioritat operativa i cues separades.
• bank-adapter: encapsula la integració amb el proveïdor bancari (SEPA Instant / API de compte). Aïllar-lo permet canviar de proveïdor sense tocar el ledger.

La consistència entre pagaments i saldos es fa amb el patró outbox: cada canvi d'estat es desa a la mateixa transacció que l'assentament i es publica a Kafka després. Motiu: evita que un pagament quedi registrat sense el seu moviment comptable o al revés.

Taules principals a PostgreSQL:

```sql -- Comptes d'usuari users(id uuid pk, phone_e164 text unique, kyc_status text, created_at timestamptz)

-- Compte de diners electrònic (un per usuari) accounts(id uuid pk, user_id uuid fk, currency char(3), status text, created_at timestamptz)

-- Assentaments: mai s'actualitzen ni s'esborren ledger_entries(id uuid pk, account_id uuid fk, transfer_id uuid null, direction char(1) check (direction in ('D','C')), amount_minor bigint check (amount_minor > 0), currency char(3), created_at timestamptz, idempotency_key text unique)

-- Transferències P2P transfers(id uuid pk, from_account uuid fk, to_account uuid fk, amount_minor bigint, currency char(3), status text, created_at timestamptz, settled_at timestamptz)

-- Retirades payouts(id uuid pk, account_id uuid fk, iban_token text, amount_minor bigint, status text, provider_ref text, requested_at timestamptz, completed_at timestamptz) ```

Decisions i motius:

• Import en unitats menors (`bigint`): elimina errors d'arrodoniment de coma flotant en diners.
• Assentaments immutables amb `idempotency_key` única: permet reintents segurs des del client i des del servei.
• Saldo com a vista materialitzada (`sum(credits) - sum(debits)` per compte), refrescada per events: lectura ràpida sense renunciar a la font de veritat.
• `iban_token` en lloc de l'IBAN en clar: minimitza dades sensibles emmagatzemades; el token es resol al proveïdor.

API REST versionada, autenticació per OAuth2 + mTLS entre serveis interns.

• `POST /v1/transfers` — crea una transferència P2P. Requereix capçalera `Idempotency-Key`. Retorna `202` amb `transfer_id`; l'estat final arriba per webhook o per consulta.
• `GET /v1/accounts/{id}/balance` — saldo actual i data de l'últim assentament.
• `GET /v1/accounts/{id}/entries?from=&to=` — extracte paginat de moviments.
• `POST /v1/payouts` — sol·licita retirada al compte bancari verificat.
• `GET /v1/accounts/{id}/export` — genera un fitxer CSV/JSON signat amb tots els assentaments. Aquest endpoint és el que fa possible una sortida ordenada i ha d'existir des del primer dia.

Integracions:

• Proveïdor bancari via `bank-adapter` (SEPA Instant per a pagaments i retirades).
• KYC amb un proveïdor extern; `kyc_status` bloqueja retirades no verificades.
• Webhooks signats (HMAC) cap a clients, amb reintents i DLQ.

Ordre deliberat, perquè cada peça protegeix la següent:

1. ledger-svc amb assentaments dobles i exportació (`/export`). És el nucli de confiança i el mecanisme de sortida.
2. payout-svc amb un proveïdor bancari en sandbox. Sense retirada real, el producte no té sentit.
3. payments-svc per a transferències P2P entre usuaris de la mateixa plataforma.
4. KYC i límits (import màxim per operació i per dia).
5. App mòbil amb saldo, historial i retirada.

Motiu de l'ordre: si el producte hagués de tancar en qualsevol moment, els passos 1 i 2 ja garanteixen que l'usuari pot treure els seus diners.

• Volum: 2 milions de clients és l'ordre de magnitud del cas real [Cinco Días, 2023-07-13]. Amb pics de 50–100 TPS en pagaments i ràfegues de retirada molt més altes en un escenari de tancament, el `payout-svc` ha d'escalar independentment.
• Risc: allau de retirades. Si s'anuncia un tancament, les retirades es multipliquen en hores. Mitigació: cues dedicades, límits per compte i un mode "sortida ordenada" que prioritza retirades sobre pagaments.
• Risc: inconsistència ledger/pagament. Mitigat amb outbox i reconciliació diària contra el proveïdor bancari.
• Risc: compliment normatiu (KYC/AML, custòdia de fons de tercers). Requereix assessorament legal; el disseny separa els fons dels usuaris del patrimoni de l'operador.
• Risc: dependència del proveïdor bancari. Mitigat per l'abstracció de `bank-adapter` i un segon proveïdor de reserva.

• Proves d'integració del ledger: cada transferència genera exactament dos assentaments que sumen zero; propietat verificada amb tests de propietat (property-based testing).
• Test d'idempotència: reintents del mateix `Idempotency-Key` no dupliquen assentaments.
• Simulacre de tancament: exercici periòdic que executa l'exportació completa i la retirada massiva en entorn de proves, mesurant temps fins a saldo zero per a tots els comptes.
• Reconciliació diària automàtica entre el ledger i el proveïdor bancari; qualsevol diferència genera alerta.
• Auditoria externa del model comptable abans del llançament, atès que el producte custodia diners de tercers.