Bnext

Bnext és una empresa de tecnologia financera (fintech) amb seu a Madrid, classificada dins del sector de software i SaaS. Segons la informació disponible, va operar com a neobanc, és a dir, com a plataforma de serveis financers d'ús mòbil adreçada a particulars.

D'acord amb les dades verificades, la societat consta com a activa al registre. Per tant, no es pot afirmar que hagi tancat.

La informació verificada disponible no detalla la data de constitució ni els fundadors. Aquestes dades no consten al corpus subministrat i caldria consultar-les al registre mercantil o a la font enciclopèdica citada.

Segons la informació disponible, Bnext oferia un compte corrent gestionat des del mòbil, pensat com a alternativa a la banca tradicional per a usuaris particulars. El model encaixa en el segment dels neobancs, que combinen aplicació mòbil i serveis de pagament.

Les dades verificades no permeten detallar productes concrets, targetes, comissions ni base d'usuaris.

El corpus disponible no inclou xifres de clients, volum de negoci, rondes de finançament ni fites concretes. Aquestes dades no consten i no es poden afirmar.

Les dades verificades indiquen que l'empresa consta com a activa al registre, de manera que no es pot confirmar un tancament. La informació disponible apunta a un procés de reestructuració o canvi de model, però el corpus subministrat no en detalla les causes, els terminis ni les decisions concretes.

Qualsevol afirmació sobre les raons d'una reestructuració requeriria fonts addicionals que no consten aquí.

El corpus disponible no permet identificar un llegat concret en termes de producte, tecnologia o mercat. Aquesta informació no consta.

Els noms dels fundadors no consten a les dades verificades. Per tant, no es pot informar sobre la seva situació actual. Per obtenir aquesta informació caldria consultar el registre mercantil (composició d'òrgans d'administració), la font enciclopèdica citada i notes de premsa especialitzada.

• En el segment dels neobancs, la rendibilitat depèn sovint de la captació massiva d'usuaris i de la monetització per intercanvi (interchange) i productes de crèdit; sense aquestes dades no es pot avaluar l'equilibri del model.
• La dependència de rondes de capital risc fa que els canvis d'estratègia o de model de negoci siguin freqüents en fintechs; convé documentar cada canvi amb fonts registrals i financeres.
• Per a qualsevol anàlisi rigorosa cal contrastar la informació enciclopèdica amb el registre mercantil i els comptes dipositats, que són les fonts que permeten verificar l'estat real de la societat.

Bnext es va concebre com un neobanc mòbil: compte, targetja i una app centrada en el control de les finances personals. Segons la informació disponible a [Wikipedia], l'empresa tenia seu a Madrid i operava al sector del software financer.

La reconstrucció més realista avui no és tornar a muntar un banc des de zero, sinó recuperar la peça que donava sentit al producte: la capa de software de gestió financera personal. És a dir, una app que agregui comptes de diversos bancs, categoritzi despeses, permeti pressupostos, estalvi automatitzat i objectius, i opcionalment ofereixi un compte de pagament lleuger recolzat en un partner regulat (entitat de diners electrònics o banc col·laborador).

Aquesta és una proposta, no una dada verificada sobre Bnext: es tracta de decidir què es podria construir avui amb la mateixa essència (control financer personal mòbil), no de replicar l'estructura societària o llicències originals, de les quals no tenim detall a la font citada.

El mercat de les finances personals digitals a Espanya és real i competitiu: hi ha bancs tradicionals amb apps millorades, neobancs establerts i apps independents d'agregació i pressupostos. La font disponible ([Wikipedia]) confirma l'existència i l'activitat de Bnext com a neobanc, cosa que valida que hi havia demanda per a un producte mòbil de finances personals en el moment del seu llançament.

El que no podem afirmar amb la font disponible és la mida exacta del mercat, la quota de Bnext ni l'evolució de la seva base d'usuaris. Qualsevol xifra de mercat que es faci servir en un pla de negoci caldrà validar-la amb fonts primàries (informes sectorials, dades de competidors, estudis d'usuaris). Com a estimació a validar, el nínxol més defensable avui és el d'usuaris que volen controlar diners repartits entre diversos bancs i que no troben prou bona l'experiència d'agregació i pressupostos a les apps bancàries tradicionals.

Proposta de model, a validar amb usuaris i amb el partner regulat:

• Subscripció premium (freemium): funcions avançades de pressupostos, estalvi automatitzat, informes i multi-compte de pagament. Preu orientatiu de mercat: rang estimat 3–8 €/mes, a validar amb enquestes de disposició a pagar.
• Compte de pagament lleuger via partner regulat: comissions d'intercanvi (interchange) sobre targetja, amb marge compartit amb el partner. El detall de repartiment és una estimació a negociar.
• B2B2C: llicenciar el motor de PFM (categorització, pressupostos, agregació) a entitats financeres o fintechs que vulguin millorar la seva app sense desenvolupar-ho internament.
• Referenciació de productes financers (estalvi, assegurances) amb comissions, sempre amb transparència i compliment normatiu.

La clau del model és no assumir el balanç ni la llicència: el negoci és software i distribució, no captació de dipòsits.

Proposta en fases, a ajustar segons validació:

1. Fase 0 – Validació (mesos 0–2): entrevistes a usuaris objectiu, definició del nínxol, selecció del partner regulat (entitat de diners electrònics o banc col·laborador) i revisió de compliment (RGPD, PSD2/agregació de comptes).
2. Fase 1 – MVP de PFM (mesos 2–6): app d'agregació de comptes via APIs obertes, categorització, pressupostos i objectius d'estalvi. Sense compte de pagament encara. Objectiu: retenció i feedback.
3. Fase 2 – Compte de pagament (mesos 6–12): integració amb el partner per a compte i targetja, amb el marge d'interchange corresponent. Requereix contracte i compliment del partner.
4. Fase 3 – Creixement i B2B (mesos 12–24): màrqueting de pagament, aliances i primeres llicències del motor de PFM a tercers.

Cada fase hauria de tenir mètriques d'entrada/sortida clares (activació, retenció a 30/90 dies, conversió a premium) abans de passar a la següent.

Estimació a validar (rang orientatiu, no són dades de Bnext):

• Equip mínim (2–4 persones: producte, enginyeria, compliment/màrqueting): rang estimat 120.000–250.000 €/any en costos de personal, segons seniority i model de contractació.
• Desenvolupament i infraestructura (MVP + integracions): rang estimat 30.000–80.000 € el primer any, incloent APIs d'agregació i núvol.
• Compliment i legal (RGPD, contractes amb partner, auditories): rang estimat 15.000–40.000 €.
• Màrqueting inicial: rang estimat 20.000–60.000 € per als primers mesos de captació.

Total orientatiu per als primers 12 mesos: rang estimat 150.000–400.000 €, a validar amb pressupostos reals de proveïdors i amb el cost concret del partner regulat. Aquestes xifres són estimacions de consultor, no dades verificades de l'empresa original.

• Regulació i compliment: operar un compte de pagament requereix un partner regulat i compliment estricte (PSD2, RGPD, prevenció de blanqueig). És el risc principal i el que encareix el projecte.
• Dependència del partner: el marge d'interchange i les condicions depenen d'un tercer; cal negociar bé i tenir pla B.
• Adquisició de clients: el cost de captació en fintech és alt i competitiu; el freemium pot créixer sense monetitzar.
• Confiança i seguretat: una app financera ha de demostrar seguretat i transparència des del dia u.
• Risc de "fer-ho tot": intentar replicar un neobanc complet des del principi és la manera més ràpida d'esgotar caixa; cal començar per la capa de software.

Les lliçons de l'experiència de Bnext, segons el que es pot extreure de la informació disponible ([Wikipedia]), apunten a un patró habitual en neobancs: la visió de producte mòbil i finances personals és potent, però el negoci és intensiu en capital i regulació, i la sostenibilitat depèn de monetitzar la relació amb l'usuari més enllà de la gratuïtat.

Per tant, el perfil que hauria de liderar la reconstrucció és un equip de producte i enginyeria fintech amb un soci de compliment/legal sòlid i un partner regulat tancat abans de llançar, no un equip que intenti obtenir llicència bancària pròpia des del primer dia. L'èxit dependrà més de la disciplina de nínxol, la retenció i la monetització que de la grandària de la visió inicial.

Segons la font disponible ([Wikipedia] Bnext — Wikipédia, https://es.wikipedia.org/wiki/Bnext), Bnext va operar com a neobanc espanyol amb compte, targeta i programa de recompenses. El coneixement que va acumular —conciliació de saldo, cicle de vida de targeta, liquidació de cashback, gestió d'incidències— és car de reconstruir i no diferencia el producte final d'una fintech.

El problema concret: una fintech o un SaaS vertical (nòmines, despeses d'equip, marketplace) que vol oferir un compte de pagament amb IBAN espanyol ha de triar entre (a) construir el nucli des de zero, 9-18 mesos, o (b) lligar-se a un BaaS genèric que no cobreix cashback ni regles de negoci. La solució proposada és un nucli de compte de pagament com a servei amb API estable, on el client conserva la marca i la UX i nosaltres garantim la consistència comptable.

Arquitectura de microserveis al voltant d'un ledger (llibre major) com a font de veritat. Cap servei escriu saldo directament: tots emeten assentaments (entries) al ledger, que és append-only i calcula saldos per projecció.

``` [Client fintech] --REST/Webhook--> [API Gateway + auth OAuth2 mTLS] | +-------------------+-------------------+ | | | [Accounts svc] [Cards svc] [Rewards svc] | | | +---------+---------+---------+---------+ | | [LEDGER (append-only)] [Outbox -> events] | | [Settlement/conciliation] [Webhook dispatcher] | [Core bancari / processador de targetes (partner)] ```

Decisions i motius:

• Ledger append-only amb projecció de saldo: garanteix auditabilitat i idempotència; el saldo mai s'actualitza in-place, s'hi deriva. Motiu: els errors de conciliació són el risc número u en comptes de pagament.
• Outbox transaccional + events: cada assentament genera un event al mateix commit; els webhooks surten de l'outbox. Motiu: evitar perdre notificacions si el dispatcher cau.
• Partner bancari per a IBAN i targetes: no som entitat de crèdit; l'IBAN i l'emissió de targeta es deleguen a un partner regulat. Motiu: complir sense llicència pròpia i reduir temps a mercat.
• Idempotency-Key obligatòria a totes les escriptures: Motiu: els clients reintentaran; duplicar un abonament és inacceptable.

Entitats principals (PostgreSQL per a estat, ledger en taula particionada per mes):

```sql -- Compte de pagament del client final account(id uuid PK, tenant_id uuid, external_ref text, iban text UNIQUE, currency char(3), status text, -- active|frozen|closed created_at timestamptz, UNIQUE(tenant_id, external_ref))

-- Assentament immutable ledger_entry(id bigserial PK, account_id uuid, entry_type text, -- credit|debit|hold|release amount_minor bigint, currency char(3), reference text, idempotency_key text UNIQUE, created_at timestamptz) -- saldo = SUM(credit) - SUM(debit) - SUM(hold) + SUM(release)

-- Targeta card(id uuid PK, account_id uuid, pan_token text, status text, -- issued|active|blocked|cancelled created_at timestamptz)

-- Regla de cashback reward_rule(id uuid PK, tenant_id uuid, mcc text[], pct numeric(5,4), monthly_cap_minor bigint, active boolean) reward_accrual(id uuid PK, account_id uuid, ledger_entry_id bigint, rule_id uuid, amount_minor bigint, status text) -- pending|settled|reversed ```

Notes de disseny:

• amount_minor bigint: mai floats per a diners.
• ledger_entry.idempotency_key UNIQUE: la base de dades és qui garanteix la no-duplicació, no el codi.
• reward_accrual.status: el cashback passa per pending→settled perquè la reversió (devolució de compra) ha de poder desfer-lo.

API REST versionada (`/v1`), autenticació OAuth2 client credentials + mTLS, totes les escriptures amb `Idempotency-Key`.

Endpoints mínims: ``` POST /v1/accounts crear compte (retorna iban) GET /v1/accounts/{id} estat + saldo projectat POST /v1/accounts/{id}/credits abonar (p.ex. nòmina) POST /v1/accounts/{id}/debits debitar POST /v1/accounts/{id}/holds retenir fons POST /v1/cards emetre targeta PATCH /v1/cards/{id} bloquejar/desbloquejar POST /v1/reward-rules definir cashback GET /v1/accounts/{id}/entries llistat paginat d'assentaments ```

Webhooks (signats HMAC-SHA256, reintents amb backoff exponencial, ordre per `account_id`): `account.created`, `entry.posted`, `card.status_changed`, `reward.settled`.

Integracions:

• Partner bancari: IBAN i liquidació via API del partner; conciliació diària per fitxer.
• Processador de targetes: autoritzacions i liquidacions; tokenització PAN.
• KYC/AML: servei extern de verificació d'identitat, cridat abans d'activar compte.

Ordre deliberat per reduir risc comptable abans de superfície:

1. Ledger + projecció de saldo + idempotència (amb tests de propietat). Sense això res més és fiable.
2. Accounts svc amb alta, abonament i consulta de saldo, recolzat en un partner bancari en mode sandbox.
3. Conciliació diària contra extracte del partner (job nocturn + alerta de desquadre).
4. Webhooks amb outbox i reintents.
5. Cards svc en sandbox (emissió i bloqueig).
6. Rewards svc amb regles per MCC i topall mensual, en mode `pending` només.
7. KYC/AML abans de permetre comptes `active` en producció.

No construir abans del punt 3: targetes reals ni cashback liquidat.

• Volum inicial: 1 tenant pilot, ~5.000 comptes, ~200k assentaments/mes. El ledger particionat per mes suporta 10× sense canvi d'esquema.
• Latència objectiu: escriptura d'assentament p95 < 150 ms; webhook lliurat p95 < 5 s.
• Risc: desquadre de conciliació → mitigació: alerta automàtica si `saldo_projectat ≠ saldo_partner` i bloqueig de debits del compte afectat.
• Risc: dependència del partner bancari → mitigació: capa d'abstracció `BankingProvider` amb interfície única; segon partner avaluable sense tocar el domini.
• Risc: compliment (PSD2/AML) → mitigació: KYC obligatori abans d'activar, registre d'auditoria immutable al ledger.
• Risc: doble abonament per reintents → mitigació: `idempotency_key` UNIQUE a nivell de BD.

• Tests de propietat del ledger: per a qualsevol seqüència d'assentaments, la suma de projecció coincideix amb el recompte directe; cap assentament duplicat amb la mateixa clau.
• Test de conciliació: injectar un extracte de partner amb una discrepància i verificar que el job la detecta i bloqueja debits.
• Test d'idempotència: enviar la mateixa petició 100 vegades i comprovar un sol assentament.
• Pilot amb un client real (una fintech o SaaS vertical) durant 8 setmanes: mètriques d'èxit = 0 desquadres no detectats, p95 de latència dins objectiu, 100% de webhooks lliurats o reintentats.
• Criteri de sortida a producció: conciliació neta 30 dies seguits en sandbox amb dades sintètiques i un extracte real del partner.