Diseño e ingeniería para founders fintech
KYC integrado. Scope PCI reducido al mínimo. Un libro mayor que aguanta una auditoría. Una app de consumo que se gana su sitio en la pantalla de inicio de quien la abre cada día.
Los problemas que más escuchamos
Onfido para el KYC, una cuenta de Stripe Connect, y un libro mayor interno del que nadie se fía del todo
Tres proveedores, y un equipo contable que a final de mes rellena hojas de cálculo para cuadrar las cifras.
Un flujo 3DS2 que pierde al cliente justo antes del clic final
Autenticaciones que rebotan, redirects del navegador, sesiones perdidas en el primer pago. El cliente acaba abriendo cuenta con un competidor.
Un responsable de compliance que te pregunta cómo demuestras que el cliente A no ve los datos del cliente B
El departamento de compras del próximo cliente regulado hará la misma pregunta. Si la respuesta solo está en la cabeza de una persona, el contrato se queda parado.
Una página de precios escrita para un ingeniero de pagos, no para el cliente final
Esquemas, BIN, redes, recargos. Quien compra quería saber cuánto iba a pagar, no cómo se llaman las cosas.
kiBank · un banco de consumo que se disuelve en el día a día
Un banco de consumo diseñado y construido entero. Sitio de marketing, app, design system, y toda la infraestructura por debajo. Dos superficies, una sola promesa, cada pantalla ganándose su sitio quitando una fricción diaria.
Dentro de la build de kiBank
Un banco de consumo vive en un teléfono. Las personas abren la app bancaria todos los días, a menudo antes del desayuno, a menudo con una sola mano en el metro. La mayoría de las apps convierte ese momento en algo caótico, estéril, o ansioso. kiBank eligió una tercera vía: un banco que se disuelve en el día a día.
El producto tenía que resultar tranquilo, comportarse rápido, y demostrar su valor en los primeros diez segundos de cada sesión. Dos superficies, una sola promesa, y cada pantalla ganándose su sitio quitando una fricción diaria. Diseñamos y construimos el ecosistema entero, desde el sitio de marketing hasta la app, pasando por el design system y toda la infraestructura por debajo. Un solo equipo, una sola base.
El design system era el proyecto
Un banco que vive en un teléfono no tiene espacio para estilos one-off. Empezamos construyendo los componentes que el sitio de marketing, la app, y eventualmente las herramientas de back-office iban a compartir, es decir botones, cards, status badges, input groups, sheet modales, filas de lista, gráficos, y el sistema de toast que muestra cada evento de transacción. Ciento veinte componentes, doscientos design tokens, una auditoría de accesibilidad que cubre lector de pantalla, control por voz y sensibilidad al movimiento. Los temas claro y oscuro comparten cada layout, cada regla de espaciado, cada curva de animación. Un cambio de tema cuesta cero round trips y sobrevive a un kill-and-relaunch de la app.
El sitio de marketing como una sola conversión
El sitio está construido alrededor de un solo resultado, es decir conseguir que el visitante instale la app antes de cambiar de pestaña. Cada sección responde a una pregunta que surge en las entrevistas con clientes, en el orden en que esas preguntas llegan. Una shell estática Next.js se sirve desde Vercel Edge en menos de 200ms en cualquier punto de Europa, y las imágenes llegan desde Cloudflare R2 con conversión AVIF al vuelo. La landing entera pesa menos que una sola foto de producto en un sitio típico de e-commerce. El hero es un teléfono, no una persona. Los proof points son silenciosos: el diseño de una tarjeta, un saldo, una notificación. La CTA es el botón de instalación.
Seis pantallas llevan el banco
La app encaja la experiencia completa en seis pantallas. La disciplina se nota desde el principio: cada tap es una decisión más profundo en un flujo, nunca un desplazamiento lateral que cueste contexto. La home lleva el saldo, la actividad reciente, y una sola acción sugerida. La pantalla de tarjeta bloquea, desbloquea, y revela los datos de la tarjeta detrás de un prompt biométrico. La actividad filtra y busca. La pantalla de envío es un único formulario que se adapta a una transferencia SEPA, a un movimiento interno, o a un pago programado sin cambiar el layout. El perfil lleva el estado KYC, los ajustes de notificación, y el canal de soporte. La pantalla de acciones de tarjeta es donde viven los límites de gasto, las tarjetas virtuales, y el bloqueo de merchant.
El banco vive en el móvil
El ochenta y tres por ciento de las sesiones ocurre desde el móvil, en movimiento, con una sola mano. El diseño móvil no parte de un wireframe, parte de la ergonomía del pulgar. Los tap targets miden al menos cuarenta y cuatro píxeles, con ocho píxeles de respiro en cada lado. La acción primaria vive en el tercio inferior de la pantalla, siempre al alcance. El teclado que se abre no empuja el contenido fuera del área visible, es el formulario el que se desplaza dentro del espacio disponible mientras la acción se queda visible. La misma librería de componentes pinta las mismas pantallas en web y en móvil. Sin re-skinning, sin codepath separado.
La confianza que nace de este diseño es operativa, no promocional. La pantalla de tarjeta revela el número solo después de un prompt biométrico y limpia el portapapeles a los treinta segundos. La pantalla de envío nunca autocompleta el importe desde la actividad anterior, porque el empujoncito equivocado con el dinero es peor que ningún empujoncito. El sistema de notificación es PSD2-compliant: las alertas de transacción llegan, pero nunca filtran el nombre del merchant ni el importe en la pantalla de bloqueo, salvo que el usuario lo haya elegido de forma explícita. Cada decisión que toca el monedero es auditable, reversible, y calibrada para la persona que mira su saldo con una sola mano mientras va al trabajo.
Por qué esta forma importa para un founder fintech
Un producto fintech no es la web de marketing más una tarjeta. Es el flujo KYC en el alta, el redirect 3DS2 en la primera compra, el libro mayor que lee el auditor, la respuesta de soporte que el cliente lee a las 11 de la noche cuando una transacción le parece rara, y el informe regulatorio que sale cada mes en el formato correcto. kiBank es la forma de trabajo que cierra todo ese circuito bajo un solo design system y una sola infraestructura, no ocho proveedores que ven cada uno una parte del cliente. El resultado es un producto que mantiene su forma cuando llega la siguiente licencia, la siguiente geografía, o la siguiente línea de producto.
Lo que el trabajo entregó
Dos superficies bajo un solo design system. Ciento veinte componentes. Doscientos design tokens. Una auditoría de accesibilidad completa sobre toda la app. Web servida por debajo de 200ms en toda Europa desde Vercel Edge. Cambio de tema de la app que cuesta cero round trips y sobrevive a un kill-and-relaunch.
Qué entregamos en este vertical
Integración KYC con Onfido o Veriff
Captura de documento, liveness check, sanctions y PEP screening, todo cableado a una state machine que el equipo de soporte puede auditar.
Libro mayor event-sourced
Partida doble, inmutable, replayable. La primera petición del auditor se resuelve con una consulta SQL, no con una reunión.
Conectores PSD2 para open banking
Account information y payment initiation vía Tink, TrueLayer, o directamente contra la API del ASPSP.
Reducción del scope PCI
Los datos de la tarjeta no tocan tus servidores. Stripe Elements o Adyen drop-in, solo tokens, el lado servidor nunca ve el PAN.
Flujo 3DS2
Cumple SCA, con una ruta redirect-back que aguanta la sesión a través de la página de challenge del emisor.
Issuing en red Visa o Mastercard
Tile en la red, BIN sponsorship vía partner BaaS si no tienes licencia propia.
Reconciliación de transacciones
Match diario a tres bandas entre libro mayor, fichero de settlement de la red y extracto bancario.
Monitoreo de fraude y AML
Motor de reglas más modelo ML más cola de revisión manual. Las transacciones sospechosas se retienen en servidor antes de llegar al cliente.
Export para reporting regulatorio
SEPA, FATCA, CRS, transaction reporting en los formatos que el regulador realmente pide.
Audit log de compliance
Cada acción privilegiada atribuida, firmada, consultable. El auditor entra con una pregunta y sale con un CSV.
Autenticación biométrica
Face ID y Touch ID al abrir la app, con fallback a passcode que no parece un downgrade.
Dashboard de customer due diligence
Vista del responsable de compliance, con revisiones pendientes, casos sospechosos, KYC vencidos, hits sobre listas de sanciones.
Notificaciones push compliant
Alertas de transacción PSD2-compliant que no revelan datos sensibles en la pantalla de bloqueo.
Bloqueo de tarjeta, límite de gasto, tarjeta virtual
Las tres funciones que el cliente busca de verdad al segundo acceso, cableadas a la misma state machine.
Un stack que encaja con el cuaderno del regulador
Cada capa de esto existe para amortizarse dos veces: la primera cuando estás poniendo en línea la primera versión del producto, la segunda cuando te encuentras delante de un regulador o un responsable de compliance que pregunta exactamente cómo responde el sistema a su pregunta. Elegimos el stack que aguanta justo en ese segundo momento.
Next.js App Router en Vercel Edge. El sitio de marketing y la webview de la app viven en el mismo runtime, con nodos edge que mantienen la callback de KYC por debajo de 200ms en cualquier punto de Europa. El redirect-back del 3DS2 aterriza en una ruta protegida por middleware edge que ya ha verificado la sesión antes de renderizar un solo byte en el navegador.
Supabase Postgres con seguridad a nivel de fila y event sourcing sobre el libro mayor. El aislamiento multi-tenant se impone en la fila, no en el código de aplicación, porque la primera pregunta de la auditoría del regulador es exactamente esa. El libro mayor es de partida doble e inmutable, con postings append-only, cada saldo derivable por replay, cada reconciliación reproducible sin stored procedure.
Stripe Elements o Adyen drop-in para los datos de la tarjeta. El PAN no toca nunca tus servidores, y el scope PCI se queda en SAQ A. Los tokens vuelven, los pagos salen, y el código se audita en una tarde en lugar de en un trimestre.
Onfido o Veriff para el KYC, cableados a una state machine que el equipo de soporte y el equipo de compliance leen desde la misma pantalla. Sanctions y PEP screening en cada alta y en cada cambio de titular efectivo, con la cola de hits alimentando directamente el dashboard de customer due diligence.
Cloudflare R2 para los documentos de los clientes, es decir documentos KYC, extractos, informes regulatorios. Cifrados en reposo con claves gestionadas por el cliente, acceso solo con URL firmada, sin costes de egress cuando el regulador pide el export completo de los últimos doce meses.
TypeScript strict de API a UI. Los renames quedan seguros, las migraciones de esquema quedan verificables, el bus factor queda en cero. Cuando el responsable de compliance que configuró las reglas deja el equipo, el producto no pierde su memoria institucional.
Preguntas que hacen los founders
¿Están regulados, o se apoyan en un partner BaaS?
No tenemos licencia propia. Para issuing, pagos o captación de depósitos nos apoyamos en un proveedor BaaS que sí la tiene, y cableamos la integración. La contraparte legal sigue siendo la entidad licenciada; nosotros nos ocupamos de la superficie del producto y del código de integración.
¿Se puede conectar con nuestro core banking actual?
Sí. Hemos integrado contra Mambu, Thought Machine, y un par de ASPSPs europeos directamente. Si vuestro core expone una API HTTP sensata y un stream de webhooks, nos conectamos. Si no lo hace, le construimos un wrapper alrededor.
¿Cómo mantienen el scope PCI al mínimo?
Los datos de la tarjeta pasan directamente del navegador a Stripe Elements o Adyen drop-in. Vuestros servidores reciben un token, nunca un PAN ni un CVV. El código termina en scope SAQ A, que es la atestación anual más barata que se puede contratar.
¿Cómo manejan el flujo 3DS2 en el primer pago?
Una ruta redirect-back mantiene la sesión a través de la página de challenge del emisor, más un fallback en el flujo móvil para cuando el cliente está dentro de la app. El cliente no vuelve a introducir nunca la tarjeta.
¿El libro mayor aguanta una auditoría financiera?
Es de partida doble, append-only, y event-sourced. El auditor recibe acceso de solo lectura sobre la tabla de postings y reconstruye cada saldo con una consulta SQL. Hemos guiado a auditores por dentro y han salido antes de lo previsto.
¿Qué hacen con sanctions screening y listas PEP?
Integramos ComplyAdvantage o Refinitiv en el alta y en cada cambio de titular efectivo. Los hits caen en una cola que el responsable de compliance limpia desde el dashboard de customer due diligence, y el cliente queda en estado pendiente hasta que la cola se cierra.
¿Cómo gestionan disputas y chargebacks?
La cola de chargebacks alimenta una sola inbox de soporte, con la notificación al merchant, la plantilla de evidence para el cardholder y el tracker de deadlines de la red, todo en una sola pantalla. El equipo que gestiona los reembolsos es el mismo que responde al chargeback, así el cliente oye una sola voz.
¿Se ocupan también de la parte regulatoria?
No. Trabajamos junto a los abogados y consultores de compliance que traen ustedes. Podemos sugerir partners con los que ya hemos enviado proyectos, pero las gestiones regulatorias no son nuestras para firmar.
Cuéntanos tu producto fintech
Una llamada para enmarcar el proyecto, un número concreto en la primera respuesta, sin teatro de agencia y sin pitch deck de case studies que parecen todos iguales.