Verse

Verse era una startup del sector fintech que operaba en el ámbito de los pagos entre particulares. Según Cinco Días, se la presentaba como competidora de Bizum. La ubicación de la empresa no consta en los datos disponibles.

No consta en los datos disponibles ninguna información sobre la fecha de fundación, los fundadores ni las circunstancias en que se creó la empresa.

Verse ofrecía servicios de pago entre particulares, es decir, transferencias de dinero entre usuarios, en un segmento dominado por Bizum. Según Cinco Días, la empresa tenía dos millones de clientes en el momento del cierre. No consta en los datos disponibles ningún detalle adicional sobre el modelo de negocio, las comisiones o los productos concretos que ofrecía.

No consta en los datos disponibles información sobre la evolución del negocio, el crecimiento, la facturación o las rondas de financiación de la empresa. El único dato sobre su dimensión es la cifra de dos millones de clientes que recoge Cinco Días en la noticia del cierre.

El 13 de julio de 2023, según Cinco Días, Verse anunció su cierre y pidió a sus dos millones de clientes que retiraran el dinero de las cuentas. La causa del cierre no consta en los datos disponibles: la fuente periodística citada recoge el anuncio y la petición de retirada de fondos, pero no una explicación verificada de los motivos.

No consta en los datos disponibles información sobre el destino de los activos, la cartera de clientes, la tecnología o la marca de la empresa tras el cierre.

No consta en los datos disponibles la identidad de los fundadores ni su trayectoria posterior. Para trazarla, se podría consultar el registro mercantil correspondiente a la sociedad, las notas de prensa de la empresa y las fuentes periodísticas especializadas en fintech que hayan seguido el sector.

• En un mercado de pagos entre particulares dominado por un operador con efecto de red (Bizum), la dimensión de la base de usuarios no garantiza por sí sola la viabilidad: Verse tenía dos millones de clientes y cerró igualmente, según Cinco Días.
• La retirada ordenada de fondos de los clientes es una operación crítica en el cierre de una fintech de pagos; el caso muestra la necesidad de planificar la comunicación y el retorno de saldos con antelación.
• La falta de datos públicos verificados sobre la causa del cierre limita el aprendizaje: para futuros análisis habría que disponer de la información registral y financiera de la sociedad, que en este caso no consta.

Reconstruir l'essència de Verse —pagaments instantanis entre persones, sense fricció, amb app mòbil— però sense intentar ser "el Bizum alternatiu" per al gran públic. La font verificada (Cinco Días, 13-07-2023) només confirma que Verse va arribar a dos milions de clients i que va demanar-los que retiressin els diners en tancar. Això indica que el producte tenia adopció, però no que el model fos rendible; la causa del tancament no consta.

La proposta, doncs, és un producte de pagaments P2P amb tres diferències respecte al P2P bancari dominant:

1. Capa de servei per a autònoms i micro-negocis: enllaços de cobrament, recordatoris automàtics, conciliació bàsica. És on el P2P gratuït deixa un buit.
2. Transferències transfrontereres SEPA instantànies amb preu clar i baix, un segment on les comissions bancàries encara són opaques.
3. Despeses compartides (pisos, viatges, grups) amb estat de comptes automàtic.

Tot això és proposta nova, no una descripció del Verse original.

L'única dada de mercat verificada és la que dona Cinco Días: Verse havia acumulat dos milions de clients abans del tancament del 2023. Això és un senyal que hi havia demanda d'alternatives al P2P bancari a Espanya, però no prova que aquesta demanda es pugui monetitzar.

La resta és anàlisi a validar:

• El P2P gratuït (Bizum i equivalents) és un producte d'engagement, no de renda: els bancs el fan servir per retenir clients, no per cobrar-lo. Competir-hi amb un producte gratuït és estructuralment difícil.
• Els segments on el P2P gratuït no arriba —cobrament professional, conciliació, transfronterer, grups complexos— són on hi ha disposició a pagar, però són mercats més petits i més exigents operativament.
• Caldrà validar amb dades pròpies (no disponibles aquí) la mida real d'aquests nínxols a Espanya i la disposició a pagar.

Proposta, a validar:

• Pla gratuït: P2P bàsic i despeses compartides, per captar usuaris i generar xarxa.
• Pla professional (estimat 5–15 €/mes): enllaços de cobrament, recordatoris, exportació comptable per a autònoms.
• Comissió per transferència transfronterera (estimació: 0,3–1 % o tarifa fixa per operació, a validar contra el mercat).
• Ingressos per intercanvi/flotació dels saldos en custòdia, si el marc regulatori ho permet (a validar amb l'assessorament legal).

La lliçó implícita del cas Verse: dos milions d'usuaris no sostenen sols un negoci si el producte principal és gratuït i no hi ha una capa de monetització clara. El model ha de néixer amb la monetització definida, no afegida després.

Fases, amb terminis estimats (a validar):

1. Mesos 0–3 · Validació: entrevistes amb 30–50 autònoms i micro-negocis; test de disposició a pagar; definició de l'abast regulatori amb un advocat fintech.
2. Mesos 3–9 · Producte mínim: P2P + enllaços de cobrament + exportació bàsica. Llicència o partner bancari per operar (la via més ràpida sol ser un partner regulat; a confirmar).
3. Mesos 9–15 · Pilot tancat: 500–2.000 usuaris en un o dos sectors (per exemple, professionals creatius i serveis a domicili).
4. Mesos 15–24 · Obertura: creixement per referits dins dels segments validats, no campanyes massives.

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

• Equip fundacional (2–3 persones, 12 mesos): estimació 150.000–300.000 €.
• Desenvolupament de producte (intern o agència): estimació 80.000–200.000 €.
• Regulació, compliance i legal (partner bancari, KYC/AML, contractes): estimació 40.000–120.000 €.
• Infraestructura i proveïdors de pagament: estimació 20.000–60.000 €/any.
• Màrqueting de validació (no massiu): estimació 30.000–80.000 €.

Rang total per als primers 12–18 mesos: estimació 320.000–760.000 €, amb un escenari mínim viable al voltant de 300.000–400.000 € si l'equip és molt petit i el producte es limita al nínxol inicial.

• Risc de model: el P2P gratuït és difícil de monetitzar; si la capa professional no converteix, el negoci no es sosté. Aquest és el risc que el cas Verse suggereix, tot i que la causa del seu tancament no consta.
• Risc regulatori: operar pagaments requereix llicència o partner; els requisits de KYC/AML encareixen l'operació i alenteixen el llançament.
• Risc competitiu: Bizum i els bancs poden replicar funcions professionals; la finestra d'avantatge és estreta.
• Risc de confiança: després de tancaments com el de Verse, caldrà explicar molt bé on és els diners dels usuaris i com es protegeixen.
• Risc de dades: no consta la causa del tancament de Verse; qualsevol conclusió sobre "què va fallar" seria especulació i no s'ha de fer servir com a base del pla.

Lliçons que es poden extreure de l'expedient original, sense inventar-ne la causa:

1. La tracció d'usuaris no és validació de negoci. Dos milions de clients (Cinco Días, 2023) no van impedir el tancament; el pla s'ha de mesurar per conversió a ingressos, no per usuaris registrats.
2. Monetitzar des del primer dia en el segment que paga. El producte gratuït ha de ser un canal, no el negoci.
3. La regulació és part del producte, no un tràmit posterior. Cal partner o llicència abans de prometre funcions.
4. Comunicar la custòdia dels diners amb claredat radical. El tancament de Verse va obligar a demanar als clients que retiressin els fons; qualsevol projecte nou ha de tenir un pla de continuïtat i comunicació explícit.
5. No competir de front amb un producte gratuït subvencionat pels bancs. Buscar el nínxol on el gratuït no arriba.

Perfil recomanat per tirar-ho endavant: un equip petit amb experiència en pagaments regulats i en vendes a autònoms, acompanyat d'assessorament legal fintech des del dia u.

Una aplicació P2P com la que oferia Verse permet enviar diners a contactes a partir d'un compte de diners electrònics custodiat pel proveïdor, no un simple embolcall sobre el compte bancari de l'usuari [Cinco Días, 2023-07-13]. Això resol la fricció d'haver d'introduir IBAN per a cada transferència petita, però crea un problema molt més dur: el proveïdor passa a ser deutor dels saldos dels clients i, per tant, ha de poder retornar-los tots, de manera ordenada i demostrable, el dia que plega.

El cas de Verse és il·lustratiu: el 13 de juliol de 2023 l'empresa va anunciar el tancament i va demanar a dos milions de clients que retiressin els diners [Cinco Días, 2023-07-13]. La font no documenta la causa del tancament ni el detall del procés de devolució, i per això aquesta especificació no assumeix cap causa: assumeix que la sortida ordenada és un requisit funcional, no una contingència.

El producte que especifico, doncs, no és només "un Bizum millor": és un sistema de diners electrònics on la reversibilitat total del passiu amb clients és una capacitat provada.

Quatre components amb responsabilitats separades i un contracte clar entre ells:

1. Ledger (llibre major): servei transaccional amb escriptura de doble entrada, immutable i append-only. És l'única font de veritat dels saldos. No coneix usuaris, telèfons ni interfícies: només comptes comptables i assentaments.
2. Core de producte: gestiona identitat, dispositius, contactes, sol·licituds de pagament i regles de negoci (límits, KYC, bloquejos). Tradueix intents de negoci en ordres al Ledger.
3. Connector bancari: adaptador cap al banc de liquidació i cap a la xarxa SEPA. Rep i envia fitxers/API de pagament, concilia extractes i alimenta el Ledger amb assentaments de liquidació.
4. Plataforma de sortida ordenada: mòdul que orquestra el tancament: congelació d'alta de nous clients, càlcul de saldos reemborsables, generació de pagaments de retorn, notificació i certificació final.

Flux d'un pagament P2P:

``` App mòbil -> Core: POST /payments (idempotency-key) -> validació KYC, límits, saldo disponible (consulta Ledger) -> Ledger: reserva de fons (assentament pendent) -> Connector: ordre de pagament SEPA (si cal sortir del sistema) -> Ledger: confirmació o reversió segons resultat -> App: estat del pagament per subscripció/polling ```

Decisions i motius:

• Ledger separat del core: perquè el tancament exigeix calcular el passiu exacte amb clients en un instant donat; barrejar-ho amb la lògica de producte faria impossible certificar el saldo.
• Idempotència obligatòria a l'API de pagaments: els reintents de xarxa mòbil són la norma; sense clau d'idempotència es dupliquen transferències.
• Connector com a adaptador: el banc de liquidació pot canviar; el Ledger no ha de saber si la liquidació és per fitxer o per API.
• Reserva prèvia de fons: evita el doble gasto quan dos pagaments simultanis competeixen pel mateix saldo.

Entitats principals (PostgreSQL per al core; el Ledger en un motor amb transaccions serialitzables, p. ex. PostgreSQL amb particionat per data):

``` users(id, phone_e164 UNIQUE, email, kyc_status, status, created_at) devices(id, user_id, push_token, platform, last_seen_at) contacts(id, owner_user_id, alias, phone_e164, display_name)

accounts(id, owner_type, owner_id, currency, kind) -- kind: user_wallet | fee_income | settlement_clearing | client_funds entries(id, txn_id, account_id, amount_minor BIGINT, direction, created_at) transactions(id, type, status, idempotency_key UNIQUE, created_at, settled_at) -- type: p2p_transfer | topup | withdrawal | refund | fee -- status: pending | posted | reversed

payment_intents(id, txn_id, debtor_account, creditor_account, amount_minor, reference) bank_orders(id, txn_id, scheme, end_to_end_id UNIQUE, status, raw_response) reconciliation_runs(id, statement_date, matched_count, unmatched_count, status) ```

Regles:

• Els imports es guarden en unitats menors enteres (cèntims) i mai en coma flotant.
• Cada `transaction` genera com a mínim dos `entries` que sumen zero per transacció; una comprovació a nivell de base de dades ho verifica.
• El saldo d'un compte no s'emmagatzema com a camp mutable: es calcula per agregació d'assentaments, amb una taula de snapshot diari per rendiment.
• `end_to_end_id` únic per ordre bancària: permet conciliar sense ambigüitat.

API pública (REST, JSON, autenticació OAuth2 amb tokens de dispositiu):

• `POST /v1/payments` amb capçalera `Idempotency-Key`; retorna `202` amb `transaction_id`.
• `GET /v1/payments/{id}` per estat.
• `POST /v1/topups` i `POST /v1/withdrawals` (aquests requereixen compte bancari verificat).
• `GET /v1/me/balance` (derivat del Ledger, no d'un camp).
• `GET /v1/me/statement?from=&to=&format=csv|pdf` per exportació fiscal.

Integracions:

• Xarxa SEPA: enviament de fitxers pain.001 i recepció de pain.002 per estat; conciliació amb extractes camt.053. Motiu: és l'estàndard que permet operar amb qualsevol banc de liquidació sense codi a mida per entitat.
• KYC: proveïdor extern via API; el resultat es desa com a esdeveniment i bloqueja o desbloqueja operacions al core.
• Notificacions: push i correu transaccional; la plataforma de sortida en depèn per comunicar el reemborsament.

Ordre estricte, perquè cada peça és prerequisit de la següent:

1. Ledger amb doble entrada i proves de conservació (suma zero, immutabilitat, reversió). Sense això, res més és auditable.
2. Alta d'usuari, KYC i compte de diners electrònics amb top-up per transferència SEPA entrant.
3. Pagament P2P intern (entre dos comptes de la plataforma) amb idempotència i reserva de fons.
4. Retirada cap a compte bancari via SEPA, amb conciliació d'estats.
5. Plataforma de sortida ordenada: congelació, càlcul de passiu, generació massiva de retorns i certificat de tancament. Es construeix aviat encara que no s'usi, perquè és el que dona sentit al conjunt.

• Volum: un producte d'aquest tipus pot arribar a milions d'usuaris; la font esmenta dos milions de clients en el cas de Verse [Cinco Días, 2023-07-13]. El Ledger s'ha de dissenyar per a escriptures sostingudes i particionat per data; el coll d'ampolla esperat és la conciliació bancària, no el registre d'assentaments.
• Risc: doble gasto en pagaments concurrents. Mitigació: reserves al Ledger amb bloqueig per compte i proves de càrrega amb concurrència.
• Risc: conciliació incompleta entre el Ledger i l'extracte bancari. Mitigació: `end_to_end_id` obligatori i un procés diari que falla sorollosament si hi ha partides no aparellades.
• Risc: tancament no provat. Mitigació: assaig de sortida ordenada en entorn d'staging amb dades sintètiques cada trimestre.
• Risc regulatori: el saldo dels clients és passiu; la font no documenta la causa del tancament de Verse [Cinco Días, 2023-07-13], i per tant no s'ha de suposar que el model és lliure de requisits de salvaguarda de fons.

• Prova d'invariants del Ledger: cada transacció suma zero; cap assentament es modifica ni s'esborra; el saldo agregat coincideix amb el snapshot diari.
• Prova d'idempotència: repetir `POST /v1/payments` amb la mateixa clau retorna el mateix `transaction_id` i no crea assentaments nous.
• Prova de conciliació: injectar extractes amb partides coincidents, duplicades i òrfenes; el sistema ha de classificar-les correctament i aturar-se si no quadra.
• Assaig de tancament: amb un conjunt de comptes amb saldos, executar la plataforma de sortida i verificar que el passiu calculat és zero després dels retorns i que el certificat llista tots els comptes afectats.
• Criteri d'acceptació global: cap client amb saldo pot quedar sense un pagament de retorn traçable o una justificació documentada del bloqueig.