Colibid

Colibid era una startup del sector fintech con sede en Valencia. La información disponible no permite precisar qué producto o servicio concreto ofrecía ni cuál era su modelo de negocio.

No consta la fecha de fundación ni el nombre de las personas fundadoras. Los datos disponibles no incluyen información sobre el proceso de constitución de la empresa.

No consta con precisión qué actividad desarrollaba Colibid dentro del sector fintech, ni qué tipo de clientes o usuarios tenía. La fuente disponible (Valencia Plaza, 25 de febrero de 2026) se limita a informar del cierre.

No consta información sobre la evolución de la empresa, su facturación, el número de clientes, las rondas de financiación o cualquier otro indicador de actividad durante su trayectoria.

La causa del cierre no consta en los datos disponibles. La única información verificada es que el diario Valencia Plaza publicó el 25 de febrero de 2026 la noticia del cierre de la startup.

No consta información sobre la continuidad de ningún producto, tecnología o equipo de Colibid tras el cierre.

No consta la identidad de los fundadores ni su situación actual. Para obtener esta información habría que consultar el registro mercantil correspondiente (Registro Mercantil de Valencia) y las fuentes periodísticas que hayan seguido la trayectoria de la compañía.

Con los datos disponibles no se puede extraer ninguna lección operativa específica sobre el sector fintech ni sobre las causas del cierre, dado que la información verificada se limita a la noticia del cese. Cualquier conclusión sobre el modelo de negocio, la gestión o el entorno de mercado requeriría fuentes adicionales que no constan en este corpus.

No hi ha prou informació pública verificada per afirmar què feia exactament Colibid més enllà de ser una fintech amb seu a València [Valencia Plaza, 2026-02-25]. Per tant, la reconstrucció no pot ser una còpia del producte original: ha de ser una proposta nova que ocupi un nínxol fintech de proximitat amb seu a València.

Proposta (a validar): una fintech lleugera de serveis financers per a pimes i autònoms de la Comunitat Valenciana, amb un producte inicial únic (per exemple, conciliació de cobraments o finançament de circulant de factures), construït sobre infraestructura regulada de tercers (open banking i un partner bancari) per reduir cost i complexitat regulatòria.

Això és una hipòtesi de treball, no una descripció del que era Colibid.

El mercat rellevant és el de serveis financers digitals per a pimes i autònoms a Espanya, i específicament a la Comunitat Valenciana, un teixit amb molta pime i autònom. La demanda de digitalització financera i de finançament de circulant és estructural, però també molt competida per bancs, fintechs nacionals i plataformes europees.

No tinc dades verificades sobre la mida d'aquest mercat ni sobre la quota que Colibid hi tenia; qualsevol xifra que es faci servir en un pla real hauria de sortir d'informes sectorials i d'entrevistes a clients potencials, no d'aquest document.

Model proposat (a validar):

• Subscripció mensual per a la capa de programari (rang estimat: 29–99 €/mes per compte, segons funcionalitats).
• Comissió per transacció o per finançament intermediat (percentatge a definir amb el partner bancari).
• Serveis d'implantació per a pimes més grans, com a ingrés inicial no recurrent.

L'objectiu seria un model d'ingrés recurrent amb marge baix per transacció i marge alt per subscripció. Tot plegat és una proposta, no una dada de Colibid.

Fases proposades (estimació de calendari, a validar):

1. Mesos 0–2: validació del problema amb 20–30 pimes valencianes; definició de l'únic producte inicial.
2. Mesos 2–5: construcció del MVP sobre infraestructura de tercers; acord amb partner regulat.
3. Mesos 5–8: pilot amb 10–15 clients reals, mesurant retenció i cost d'adquisició.
4. Mesos 8–12: llançament comercial limitat a la Comunitat Valenciana i decisió sobre escalar o pivotar.

La disciplina de no escalar fins a tenir retenció demostrada és, probablement, la lliçó més important que es pot extreure d'un tancament com el de Colibid, tot i que la causa no consta.

Xifres estimades i a validar, no dades de Colibid:

• Equip fundador mínim (2–3 persones, 12 mesos): rang de 120.000–200.000 € en sous i càrregues.
• Desenvolupament del MVP: rang de 40.000–90.000 € si es fa amb equip propi reduït; més si s'externalitza.
• Compliment i acords amb partners regulats: rang de 15.000–40.000 € (assessoria legal i tècnica).
• Màrqueting i vendes inicials: rang de 20.000–50.000 €.
• Costos generals (oficina, eines, assegurances): rang de 15.000–30.000 €.

Total orientatiu per als primers 12 mesos: rang de 210.000–410.000 €, a validar amb un pressupost detallat. No és una xifra de Colibid ni una previsió de retorn.

• Risc de producte: reconstruir sense saber què va fallar a Colibid (la causa no consta) pot repetir errors. Cal validar el problema abans de construir.
• Risc regulatori: operar en fintech exigeix compliment; fer-ho via tercers redueix risc però limita marge i control.
• Risc de mercat: competència de bancs i fintechs consolidades amb més capital.
• Risc financer: el rang de cost inicial és significatiu per a un equip petit; cal finançament o ingressos propis.
• Risc de concentració geogràfica: començar només a València limita l'escala i caldrà un pla de sortida regional.

Les lliçons que es poden extreure d'aquest cas, més enllà de Colibid:

• No reconstruir a cegues: quan la causa del tancament no consta, el primer pas és la recerca, no el codi.
• Validar abans d'invertir: el cost real d'un MVP sense demanda validada és el pitjor escenari.
• Dissenyar per a la sostenibilitat: un model d'ingrés recurrent i cost controlat és més resilient que el creixement per si mateix.
• Aprofitar l'entorn local: València té teixit pime i ecosistema emprenedor; és un bon lloc per començar petit i aprendre.

Aquest informe és una proposta de reconstrucció, no una continuïtat verificada de Colibid.

Les pimes valencianes amb factures impagades o préstecs fallits no tenen un canal eficient per cedir aquest deute: els despatxos de cobrament els ofereixen preus opacs i els fons institucionals no arriben a tiquets petits. Colibid hauria atacat aquesta asimetria d'informació amb una subhasta inversa on el cedent fixa el preu mínim i els compradors liciten a la baixa sobre el descompte, amb un historial de recuperació verificat per lot. El tancament el 2026 [Valencia Plaza, 2026-02-25] no invalida el problema de mercat; la especificació parteix de la hipòtesi que el producte era correcte i el model d'ingressos o la captació el que va fallar.

Tres serveis independents desplegats en contenidors sobre un clúster Kubernetes, amb una base de dades PostgreSQL en mode primary-rèplica i un object store S3 per als expedients documentals.

``` [Web cedent] [Web fons] [API partners] \ | / \ | / +--- API Gateway (Kong, JWT + rate limit) ---+ | +-----------------+------------------+ | | | [auction-svc] [scoring-svc] [ledger-svc] (Go, licitació) (Python, ML) (Go, escriptures) | | | +--------+--------+---------+--------+ | | [PostgreSQL] [S3 expedients] | [Kafka: events de subhasta] ```

Motius de les decisions:

• Go per a auction-svc i ledger-svc: la subhasta té pics de concurrència en els últims 60 segons i necessita bloquejos deterministes; Go amb goroutines i transaccions PostgreSQL `SERIALIZABLE` evita condicions de cursa en el tancament.
• Python per a scoring-svc: l'equip de risc treballa amb scikit-learn i necessita iterar ràpid; se serveix com a API interna amb model versionat a MLflow.
• Kafka entre serveis: el tancament de subhasta ha de disparar escriptures al ledger i notificacions sense acoblament temporal; si el ledger cau, els events queden al topic i es reprocessen.
• Segellat d'ofertes amb commit-reveal: les ofertes s'envien xifrades amb la clau pública del lot i només es desxifren en el tancament, de manera que ni l'operador pot veure-les abans; el hash del compromís queda al ledger.

Entitats principals (PostgreSQL, esquema `colibid`):

```sql cedent(id UUID PK, cif TEXT UNIQUE, nom TEXT, kyc_estat TEXT, creat_el TIMESTAMPTZ) lot(id UUID PK, cedent_id UUID FK, tipus TEXT, import_nominal NUMERIC(14,2), divisa CHAR(3), data_venciment DATE, preu_minim_pct NUMERIC(5,2), scoring_id UUID FK, estat TEXT, creat_el TIMESTAMPTZ) document(id UUID PK, lot_id UUID FK, s3_key TEXT, tipus TEXT, hash_sha256 TEXT) subhasta(id UUID PK, lot_id UUID FK, obertura TIMESTAMPTZ, tancament TIMESTAMPTZ, estat TEXT, clau_publica TEXT) oferta(id UUID PK, subhasta_id UUID FK, fons_id UUID FK, compromis_hash TEXT, payload_xifrat BYTEA, descompte_pct NUMERIC(5,2), creat_el TIMESTAMPTZ, UNIQUE(subhasta_id, fons_id)) adjudicacio(id UUID PK, subhasta_id UUID FK, oferta_id UUID FK, preu_final NUMERIC(14,2)) escriptura_ledger(id BIGSERIAL PK, tipus TEXT, referencia UUID, hash_previ TEXT, hash_actual TEXT, creat_el TIMESTAMPTZ) ```

Decisions:

• `preu_minim_pct` expressat com a percentatge del nominal, no com a import absolut, perquè el cedent pugui reutilitzar plantilles de subhasta.
• `escriptura_ledger` encadenada per hash (cada fila inclou el hash de l'anterior) per donar prova d'integritat davant d'una eventual disputa sobre l'adjudicació.
• `UNIQUE(subhasta_id, fons_id)` impedeix que un fons saturi la subhasta amb ofertes múltiples i distorsioni el descompte.

API REST versionada (`/v1`) amb OpenAPI 3.1 com a contracte font.

• `POST /v1/lots` — el cedent crea un lot; retorna `lot_id` i puja els documents per URL prefirmada S3.
• `POST /v1/lots/{id}/subhasta` — obre la subhasta amb `clau_publica` generada pel servei (X25519).
• `POST /v1/subhastes/{id}/ofertes` — el fons envia `compromis_hash` i `payload_xifrat`; idempotència per `Idempotency-Key`.
• `POST /v1/subhastes/{id}/tancament` — endpoint intern, només invocable pel scheduler; desxifra, ordena i adjudica.
• `GET /v1/subhastes/{id}/resultat` — retorna l'adjudicació i el rastre del ledger.

Integracions:

• KYC de cedents i fons: proveïdor extern (p. ex. Sumsub) via webhook signat; cap lot no passa a `obert` sense `kyc_estat = aprovat`.
• Signatura electrònica del contracte de cessió: API de signatura (p. ex. Signaturit) que rep el PDF generat pel servei i retorna el document signat, arxivat a S3 amb hash al ledger.
• Escrow de pagament: compte segregat via API bancària (p. ex. Stripe Connect o un PSP amb compte escrow); l'adjudicació només es tanca quan el fons ha dipositat el `preu_final`.

1. Cicle de subhasta d'un lot amb commit-reveal i escrow (auction-svc + ledger-svc + integració de pagament). És el nucli del producte i on es concentra el risc legal; sense això no hi ha producte.
2. KYC i generació del contracte de cessió signat. Sense contracte signat i dipòsit en escrow, l'adjudicació no és executable i el mercat no és creïble.
3. Scoring de recuperabilitat bàsic (regles + model simple sobre historial de cobrament). Es pot llançar amb un model heurístic i iterar; no bloqueja el cicle.
4. Portal del cedent i del fons amb estat de subhasta en temps real via WebSocket.

• Concurrència al tancament: si 200 fons liciten en els últims 60 segons, el desxifrat i l'ordenació han de ser deterministes. Risc de condició de cursa si el scheduler s'executa en més d'una rèplica; mitigació: lock distribuït a PostgreSQL (`pg_advisory_lock`) sobre `subhasta_id`.
• Mida dels expedients: un lot pot portar centenars de factures; S3 amb URL prefirmada i límit de 200 MB per lot. El scoring ha de processar mostres, no el total, per mantenir latència < 2 s.
• Risc legal de la cessió de crèdits: la cessió de crèdits entre particulars i empreses té requisits de notificació al deutor; el servei ha de generar la notificació i registrar-la al ledger. Risc de producte si el marc legal canvia.
• Risc de model: el scoring pot sobreestimar la recuperabilitat i fer que els fons paguin de més; mitigació: mostrar interval de confiança i historial de recuperació real per lot, no només el score.
• Risc de liquiditat: el mercat necessita massa crítica de fons; si no n'hi ha prou, les subhastes queden desertes. Mètrica de seguiment: ràtio de subhastes amb almenys 3 ofertes.

• Test d'integració del cicle complet: crear lot → obrir subhasta → 3 ofertes xifrades → tancament → adjudicació → dipòsit escrow → contracte signat, amb assercions sobre el ledger encadenat.
• Test de concurrència: 500 ofertes simultànies en els últims 10 segons; verificar que el resultat és idèntic executant el tancament dues vegades (idempotència) i que el ledger no té forks.
• Test de seguretat: verificar que `payload_xifrat` no és llegible per l'operador abans del tancament (accés directe a la BD) i que el `compromis_hash` detecta manipulació.
• Validació de mercat: pilot amb 20 cedents i 5 fons durant 8 setmanes; mètriques d'èxit: ≥ 60% de lots amb oferta, descompte mitjà d'adjudicació dins del rang esperat pel scoring, i zero disputes sobre l'adjudicació.
• Auditoria del ledger: script que reconstrueix la cadena de hash i detecta qualsevol escriptura trencada; s'executa a cada desplegament.