Data dividends — el usuario gana Açaí

Cuando un comercio reusa la identidad verificada de una persona a través del wallet de bjungle, la persona recibe 5 Açaí. Es la propuesta que distingue al wallet de cualquier otro reuso-de-KYC en LATAM o global.

El split — 20 / 7 / 5

Cada presentación de wallet aprobada cuesta 32 Açaí al comercio que la solicita. Esos 32 se distribuyen:

Receptor	Açaí	Razón
bjungle	20	custodia, operación, motor de consent
Tenant origen (quien hizo el KYC primero)	7	infraestructura inicial + incentivo a verificar bien
Usuario	5	retribución por consentimiento informado

A la tasa pública del Açaí (~ COP 60 / Açaí), el usuario recibe ≈ COP 300 por cada aprobación. Un usuario activo puede ser reusado 3-8 veces al año, lo que rinde COP 1.000-2.500 anuales por mantener el wallet activo. Cantidad pequeña en absoluto, pero significativa por dos razones:

Es ingreso recurrente sin esfuerzo. El usuario aprobó un KYC una vez; los siguientes “ingresos” requieren solo tocar “Aprobar” en una pantalla.
Es el único modelo donde el usuario recibe algo. Stripe Identity, Persona, Trulioo: el reuso debita al comercio nuevo y acredita al proveedor del KYC original. El sujeto verificado no participa del valor.

Por qué no es venta de datos

La legislación colombiana (Ley 1581, Ley 1266) y el régimen GDPR-equivalente distinguen claramente entre:

Venta de datos — el controlador cede datos a un tercero a cambio de contraprestación, sin consentimiento informado del titular.
Retribución por consentimiento informado — el titular acepta una contraprestación específica a cambio de una autorización específica.

El modelo de data dividends está diseñado para encajar en la segunda categoría:

El usuario es controlador — sus VCs viven en su wallet, firmadas por bjungle pero no propiedad de bjungle (ver Modelo C).
El consentimiento es específico — la pantalla /consent/$token muestra exactamente qué claims se comparten, con qué tenant, por cuánto tiempo, y a cambio de cuántos Açaí. No hay tracking pasivo ni opt-in genérico al onboarding.
La contraprestación es transparente — los 5 Açaí están visibles ANTES de aprobar, no escondidos en una notita al pie. El usuario sabe exactamente qué recibe.
El usuario puede revocar — en cualquier momento desde /v1/wallet/me/grants (UI: pestaña “Accesos” de la PWA).

La promesa al usuario es visible — no a medias

Tres lugares donde el usuario ve los 5 Açaí ANTES de aprobar:

Cashback callout en el consent screen — primer bloque del card, en el color bmonkey-50 que es el dorado del wallet. Imposible no notarlo.
Etiqueta del botón primario — “Aprobar y recibir 5 Açaí” (no “Aprobar”). El verbo siempre carga el valor que el usuario gana.
Pantalla de éxito post-approve — “+5 Açaí acreditados ahora · Tu balance: 127 Açaí”. Inmediato, sin animación que se pueda perder por prefers-reduced-motion.

Y tres lugares donde el usuario ve el split completo POST-aprobación:

/grants → expandir card — “Cuánto ganaste: +5 Açaí · de los 32 Açaí que pagó”.
/ledger — historial con cada entrada +5 Açaí · Comercio X usó tu identidad.
Home — el balance total en text-6xl bmonkey-700, el componente visualmente más grande de toda la app.

Cómo se ejecuta atómicamente

El movimiento 20 / 7 / 5 es la operación más delicada del wallet — toca:

el balance del comercio solicitante (PostgreSQL bjungle_platform, débito)
el balance del tenant origen (PostgreSQL bjungle_platform, crédito)
el balance del usuario (PostgreSQL bjungle_bmonkey, crédito) — misma transacción que la creación del grant
el evento bmonkey.presentation.granted al webhook del tenant solicitante

Para que la inconsistencia entre las dos bases lógicas nunca quede expuesta, usamos outbox pattern (migración 0009):

La aprobación commitea EN bmonkey: el grant, el +5 al usuario, dos filas en acai_outbox (-32 al solicitante, +7 al origen), y una en events_outbox (la notificación).
Si bmonkey commiteó, la operación es definitiva desde el punto de vista del usuario (vio “+5 Açaí” en pantalla).
El worker bmonkey-worker drena el outbox con retry/backoff (30s · 2m · 15m · 1h · 6h · 24h) → llama platform-api para mover los Açaí entre tenants → si falla persistentemente, el row queda en DLQ visible para ops.

Esto importa porque la propuesta de valor depende de que el usuario nunca vea “+5 Açaí prometido” y un balance que no se actualiza. Y por simetría, el comercio solicitante nunca queda debitado sin que el origen reciba su crédito.

¿Es replicable por la competencia?

Técnicamente sí. Estructuralmente no fácil:

Stripe Identity opera con margen agresivo + escala global; bajar el precio de reuso para meter al usuario rompe la curva de utilidad.
Trulioo / Persona venden por suscripción enterprise; el “usuario final” no es su cliente, no tienen forma natural de transferirle valor.
Reuso de KYC entre bancos cooperativos en LATAM existe pero requiere coordinación regulatoria. El modelo bjungle es el primero que lo hace con incentivo al titular en producto.

El moat real no es la tecnología — es la convención. Una vez que un usuario empieza a recibir Açaí por aprobar, su próximo flujo de identidad con cualquier wallet sin dividends se siente peor.

Estado de la implementación

Componente	Estado
Migración `user_acai_balance` + ledger	✅ 0007
Crédito atómico in-tx del approve	✅ T10
Visibilidad en consent screen + home + grants	✅ T13-T14
Webhook fan-out del split	✅ outbox + worker
Pantalla de redención (loyalty)	⏳ futuro
Transferencia a banco vía partner	⏳ requiere alianza
Revisión legal procedural	⏳ engagement abierto

Referencias

Migración: bmonkey/backend/db-bmonkey/migrations/0007_user_dividends.up.sql
Service approve: bmonkey/backend/go-bmonkey-api/internal/service/wallet_service.go::ApproveConsent
Catálogo Açaí: platform/backend/go-platform-api/internal/domain/acai_pricing.go
BACKLOG: bmonkey — Data dividends (recompensas al usuario por reuso)