Sequra

Segons les dades verificades, Sequra és una startup del sector del software i SaaS ubicada a Barcelona (Barcelona), amb estat registral actiu. La razó social que consta a les dades és "SEGUROS SEGURA".

No consta cap informació que permeti descriure l'activitat concreta, el producte o el model de negoci més enllà de la classificació sectorial indicada.

No consta. Les dades disponibles no inclouen any de fundació, fundadors ni circumstàncies de la creació de l'empresa.

No consta. La informació disponible només indica el sector (software i SaaS) i la ubicació, sense detallar productes, clients o mercats.

No consta. No es disposa de dades de facturació, creixement, finançament o fites comercials.

No consta cap tancament. D'acord amb les dades verificades, l'estat registral de l'empresa és actiu, de manera que no es pot parlar de cessament d'activitat.

No consta. No hi ha informació sobre impacte, continuïtat o llegat de l'empresa.

No consta. Les dades no identifiquen les persones fundadores. Per obtenir aquesta informació caldria consultar el registre mercantil (BORME i Registre Mercantil de Barcelona) i fonts primàries de l'empresa.

No es pot extreure cap lliçó operativa específica del sector a partir de les dades disponibles, perquè no consten fets sobre l'evolució, les decisions o els resultats de l'empresa. Qualsevol conclusió seria una suposició i, per tant, no es formula.

Nota sobre fonts: l'única font indicada és una referència de Wikipedia ([Wikipedia] Sequra — Wikipédia — https://es.wikipedia.org/wiki/Grupo_Segura). Aquesta referència no s'ha pogut fer servir per afirmar fets concrets sobre Sequra, i caldria verificar-la i contrastar-la amb fonts registrals i primàries abans de documentar cap aspecte de l'empresa.

Segons la font disponible [Wikipedia], Sequra s'associa al finançament de compres al punt de venda per a comerç electrònic (el que avui s'anomena BNPL, buy now pay later). Aquesta és l'essència que es podria reconstruir.

Proposta (no fet verificat): construir avui una infraestructura de pagament fraccionat per a comerços en línia, oferta com a API/SaaS que el comerciant integra al seu checkout, amb el finançament proveït per entitats col·laboradores i el risc de crèdit gestionat amb scoring propi. La diferència respecte de l'original seria de posicionament, no d'essència: menys producte de consum massiu i més enfocament en verticals on el ticket mitjà i la recurrència justifiquen el cost d'adquisició.

Això és una hipòtesi de treball. No tenim, a les dades verificades, detalls del producte original, del seu model de comissions ni de la seva base de comerciants, i per tant no s'afirma cap xifra sobre això.

El mercat del pagament fraccionat al comerç en línia existeix i està poblat per actors consolidats, tant proveïdors especialitzats com els mateixos processadors de pagament i els bancs. Aquesta és una afirmació de context general, no una dada verificada sobre Sequra.

A validar abans de res: mida i creixement del segment al mercat espanyol i europeu, quota dels incumbents, i —el més important— si queda espai per a un entrant nou o si el joc ja és de marges prims i escala. Un pla de reconstrucció honest ha de començar per aquí, no per la tecnologia.

Proposta: tres fonts d'ingrés, totes a validar.

1. Comissió per transacció al comerciant (percentatge sobre el volum finançat).
2. Comissió de plataforma/SaaS per integració i eines de gestió.
3. Marge financer sobre el finançament, si es fa amb balanç propi o amb un soci de capital.

El punt crític és el risc de crèdit: en BNPL, el marge es decideix tant per la comissió com per la morositat. Estimació (a validar): la rendibilitat dependrà de mantenir la pèrdua per impagament per sota d'un dígit baix sobre el volum, xifra que cal contrastar amb dades reals del sector.

Proposta, per fases:

• Fase 0 (mesos 0-2): validació. Entrevistes amb comerços, anàlisi de la competència i decisió sobre si el producte és viable avui. Si la conclusió és que no, aturar aquí és un èxit, no un fracàs.
• Fase 1 (mesos 2-6): producte mínim amb un soci financer (per no carregar balanç) i 5-10 comerços pilots.
• Fase 2 (mesos 6-12): integració API estable, scoring bàsic i primeres mètriques de morositat reals.
• Fase 3 (mesos 12-24): escalat comercial si les mètriques de la fase 2 ho justifiquen.

Tot són estimacions i rangs, a validar amb pressupostos reals:

• Equip fundacional (2-3 persones: producte, enginyeria, risc/comercial): rang estimat de 150.000-300.000 € anuals, segons sous de mercat a Barcelona.
• Desenvolupament del producte i integracions: rang estimat de 50.000-150.000 € en el primer any, si es fa amb equip propi reduït.
• Compliment normatiu i legal (protecció de dades, contractes amb socis financers, possible llicència o acord amb entitat regulada): rang estimat de 30.000-80.000 €, molt dependent de l'estructura triada.
• Màrqueting i adquisició de comerços pilots: rang estimat de 30.000-100.000 € el primer any.
• Capital de treball / cobertura de morositat inicial: si es finança amb balanç propi, aquesta és la part més gran i més volàtil; si es fa amb soci, es tradueix en cost financer. Rang molt preliminar: 100.000-500.000 €, a definir segons el model.

Total orientatiu del primer any: rang estimat de 350.000-1.000.000 €, amb la forquilla alta reservada a qui financi amb balanç propi. Són xifres de treball, no un pressupost.

1. Risc de mercat saturat: els incumbents tenen escala i cost de capital baix; un entrant nou competeix amb desavantatge estructural.
2. Risc de crèdit: la morositat pot menjar-se el marge; cal modelar-la abans d'escalar.
3. Risc regulatori: el finançament al consum està regulat i canvia; cal assessorament legal des del dia u.
4. Risc de dependència de socis financers: si el capital ve de tercers, el marge i la flexibilitat es redueixen.
5. Risc de dades: no tenim informació verificada suficient sobre l'empresa original; qualsevol decisió basada en aquest informe ha de contrastar-se amb fonts primàries.

Aquesta secció recull les lliçons de l'informe original, no un perfil de candidat.

La lliçó principal és que la reconstrucció no és una còpia, sinó una decisió d'inversió: cal algú que accepti començar per la validació del mercat i estigui disposat a aturar-se si les dades no acompanyen. La segona lliçó és que el risc de crèdit és el cor del negoci, no un detall operatiu; qui ho lideri ha de tenir criteri financer, no només tecnològic. La tercera és que les dades verificades són escasses i l'informe ho ha de dir: qualsevol xifra d'aquest document és una hipòtesi a contrastar amb fonts primàries abans de comprometre capital.

Les botigues en línia petites i mitjanes perden vendes quan el client no vol o no pot pagar la totalitat en el moment de la compra. Les passarel·les de targeta tradicionals no ofereixen finançament, i les solucions BNPL existents solen exigir volums mínims, integracions feixugues o comissions opaques. El resultat és un carretó abandonat i un comerciant que no pot competir amb els grans.

La solució és una capa de pagament que s'integra al checkout del comerciant amb una crida d'API, decideix en temps real si finança el client en quotes setmanals sense interessos, i liquida al comerciant l'endemà. La plataforma assumeix el risc de crèdit, de manera que el comerciant no ha de perseguir impagaments ni gestionar devolucions financeres.

Aquesta descripció és una inspiració de producte: el document no afirma res sobre l'operativa interna real de l'empresa esmentada, sinó que especifica una solució tècnica pròpia basada en el model de negoci del sector.

Arquitectura de microserveis amb un nucli síncron de baixa latència (decisió de crèdit i autorització) i un pla asíncron per a liquidacions, cobraments i notificacions. Motiu: la decisió de crèdit ha de respondre dins del checkout del comerciant (pressupost de 300 ms), mentre que la liquidació i els cobraments poden trigar hores i no han de bloquejar la compra.

``` [Botiga] --(JS widget)--> [API Gateway] --> [Checkout Service] | +--> [Credit Decision Service] --> [Bureau Adapter] | --> [Feature Store] +--> [Order Service] --> [Postgres] +--> [Ledger Service] --> [Postgres]

[Order Service] --event--> [Kafka] --> [Settlement Worker] --> [Bank Payout Adapter] --> [Repayment Scheduler] --> [PSP Adapter] --> [Notification Worker] --> [Risk Monitoring Worker] ```

• API Gateway: autenticació per clau d'API del comerciant, rate limiting i idempotència per `Idempotency-Key`. Motiu: protegir el nucli de pics de tràfic i evitar dobles càrrecs.
• Checkout Service: orquestra la decisió i crea l'ordre. Sense estat, escalable horitzontalment.
• Credit Decision Service: motor de regles + model de puntuació. Consulta un feature store (Redis) amb historial del client i un adaptador a un bureau de crèdit extern. Motiu: separar la lògica de risc del flux de pagament permet desplegar models sense tocar el checkout.
• Order Service: font de veritat de l'ordre i el seu estat (màquina d'estats explícita).
• Ledger Service: llibre de doble entrada per a cada moviment financer. Motiu: auditabilitat i conciliació; cap saldo es calcula sumant ordres, sempre es deriva del llibre.
• Kafka: bus d'esdeveniments per desacoblar liquidació, cobraments i notificacions. Motiu: tolerància a caigudes dels adaptadors bancaris i re-processament.
• Adaptadors externs: PSP (cobrament de quotes), banc (payout al comerciant), bureau (consulta de solvència), correu/SMS.

PostgreSQL per al nucli transaccional; Redis per a features i idempotència; object storage per a documents (contractes, justificants). Motiu: Postgres ofereix transaccions ACID per al llibre i les ordres; Redis dóna latència sub-mil·lisegon per a la decisió.

Entitats principals (esquema simplificat):

```sql merchant(id, legal_name, api_key_hash, payout_iban, status, created_at) customer(id, email_hash, phone_hash, kyc_status, created_at) -- dades personals minimitzades order(id, merchant_id, customer_id, amount_cents, currency, status, idempotency_key, created_at) order_item(id, order_id, sku, qty, unit_price_cents) installment_plan(id, order_id, n_installments, first_due_date, status) installment(id, plan_id, seq, due_date, amount_cents, status, psp_charge_id, paid_at) ledger_entry(id, account, debit_cents, credit_cents, ref_type, ref_id, created_at) decision(id, order_id, score, rules_version, model_version, outcome, latency_ms, created_at) payout(id, merchant_id, period_start, period_end, amount_cents, bank_ref, status) ```

• `order.status`: `CREATED → APPROVED → CAPTURED → SETTLED → CLOSED`, amb branques `DECLINED`, `CANCELLED`, `REFUNDED`. Transicions validades al servei, no a la BD.
• `installment_plan`: per defecte 4 quotes setmanals (configurable per comerciant). Motiu: és el format més habitual del sector i redueix la fricció de comprensió.
• `decision` guarda `rules_version` i `model_version` per reproduir qualsevol decisió passada. Motiu: requisit d'auditoria i de reclamacions.
• `ledger_entry` amb comptes: `merchant_payable`, `customer_receivable`, `platform_fee`, `cash`. Cada ordre genera entrades balancejades.
• Retenció: dades personals minimitzades (hash d'email/telèfon) i purga segons política de retenció; el llibre es conserva per obligació comptable.

API REST versionada (`/v1`), JSON, autenticació per clau d'API al header `Authorization: Bearer <key>`. Totes les escriptures requereixen `Idempotency-Key`.

Endpoints del comerciant:

• `POST /v1/checkout/sessions` — crea una sessió de checkout; retorna `session_id` i URL del widget. Cos: `{amount_cents, currency, items[], customer{email,phone}}`.
• `GET /v1/checkout/sessions/{id}` — estat i resultat de la decisió.
• `POST /v1/orders/{id}/capture` — confirma la comanda després de la decisió favorable.
• `POST /v1/orders/{id}/refund` — refús total o parcial; recalcula quotes i llibre.
• `GET /v1/payouts?from=&to=` — liquidacions del comerciant.
• `POST /v1/webhooks` — registre d'endpoints; esdeveniments: `order.approved`, `order.declined`, `order.settled`, `installment.paid`, `installment.failed`, `refund.processed`.

Integracions externes:

• Bureau de crèdit: consulta síncrona amb timeout de 150 ms i circuit breaker; si cau, es recorre a regles locals (degradació controlada) i es marca la decisió com a `degraded`.
• PSP: cobrament de cada quota amb reintents exponencials (3 intents) i dunning posterior.
• Banc (payout): fitxer SEPA o API bancària; conciliació per `bank_ref`.
• Webhooks sortints: signats amb HMAC-SHA256 i reintents amb backoff; esdeveniments idempotents per `event_id`.

Contracte de decisió (resposta del checkout): ```json { "session_id": "cs_123", "decision": "APPROVED", "installments": [ {"seq":1,"due_date":"2025-01-10","amount_cents":2500}, {"seq":2,"due_date":"2025-01-17","amount_cents":2500}, {"seq":3,"due_date":"2025-01-24","amount_cents":2500}, {"seq":4,"due_date":"2025-01-31","amount_cents":2500} ], "expires_at": "2025-01-03T12:00:00Z" } ```

Ordre pensat per tenir un flux de diners complet i auditable al més aviat possible, amb el mínim de superfície:

1. Ledger Service + Order Service amb màquina d'estats i Postgres. Sense llibre no hi ha producte financer; es construeix abans que res.
2. Checkout Service + API Gateway amb idempotència i el widget JS mínim (botó "Paga en 4 quotes").
3. Credit Decision Service v1 basat en regles (import, historial al comerciant, llista de bloqueig), sense model ML. Motiu: validar el flux abans d'invertir en modelatge.
4. Adaptador PSP per cobrar la primera quota i les següents, amb reintents.
5. Settlement Worker + payout al comerciant (T+1) i conciliació bàsica.
6. Webhooks i panell del comerciant (llistat d'ordres i liquidacions).
7. Model de puntuació i feature store un cop hi ha volum suficient de decisions etiquetades.

• Latència de decisió: objectiu p95 < 300 ms. Risc: la consulta al bureau domina la latència; mitigació amb timeout de 150 ms, caché de resultats recents i circuit breaker.
• Risc de crèdit: la plataforma assumeix l'impagament. Risc tècnic associat: un model mal calibrat genera pèrdues. Mitigació: límits per client i per comerciant, kill switch per aturar el finançament, monitoratge de la taxa d'impagament per cohort.
• Consistència financera: dobles càrrecs o liquidacions duplicades. Mitigació: idempotència a totes les escriptures, llibre de doble entrada, conciliació diària automàtica.
• Compliment normatiu: KYC/AML i protecció de dades. Risc: retards per requisits legals. Mitigació: minimitzar dades des del disseny i integrar un proveïdor KYC especialitzat.
• Volum inicial: disseny per a 10-50 comandes/minut amb marge; l'escalat horitzontal dels serveis sense estat cobreix pics de campanyes.
• Dependència de tercers: caiguda del PSP o del banc bloqueja cobraments/liquidacions. Mitigació: cua Kafka, reintents i estat explícit `PENDING` visible al comerciant.

• Proves de contracte entre Checkout, Order i Ledger amb esquemes versionats; cap canvi d'API sense tests de compatibilitat.
• Proves d'idempotència: repetir la mateixa `Idempotency-Key` no ha de crear ordres ni càrrecs duplicats.
• Proves de la màquina d'estats: totes les transicions vàlides i invàlides cobertes; cap estat final no pot tornar enrere.
• Conciliació automàtica: cada nit es verifica que `sum(debits) == sum(credits)` al llibre i que les liquidacions quadren amb les ordres `SETTLED`.
• Càrrega: test de 50 comandes/minut amb p95 de decisió <