Aleks Sánchez Logo
Aleks Sánchez
Volver a todos los proyectos
PortfolioMap · Lente 1 · BankingEn producción · portfoliomap · live

Banking: cuentas, tarjetas y un ledger unificado en PortfolioMap

La capa bancaria de PortfolioMap. Cuentas multi-divisa, tarjetas (debit, credit, virtual), ledger unificado, transfers SEPA/SWIFT/P2P y wallet FX de 8 divisas — todo bajo el mismo design system.

Mi rolProduct Designer · sistema de componentes en React
CuándoEn desarrollo · 2026
EquipoSolo founder por ahora — diseño, sistema y producto
StackVite + SWC, React 18, TypeScript estricto, Tailwind con tokens HSL, shadcn/ui (Radix), lucide-react, react-router v6 (HashRouter), Storybook 10, MCP servers
Banking: cuentas, tarjetas y un ledger unificado en PortfolioMap

Resultados

6 cuentas multi-divisa

desde €5.640 hasta €1.2 B firm AUM, todas con saldo nominal y EUR

6 tarjetas, 3 networks

Visa / MC / Amex en debit, credit y virtual con freeze instantáneo y rewards

8 divisas en wallet FX

EUR, USD, GBP, CHF, JPY, AUD, CAD, CNH con conversiones programadas y hedge

El problema que ataca el módulo

El usuario fintech vive disperso entre apps. Banking en PortfolioMap los une en una vista:

  • Una para banking diario, otra para FX, otra para tarjetas virtuales, otra para SEPA Instant y SWIFT.
  • Cuenta multi-divisa, tarjeta virtual con tokenization y SWIFT con SCA pendiente conviven en la misma pantalla.
  • Mismo design system, mismo audit trail, mismo flujo de excepciones.

Proceso y validación

  • Hipótesis inicial: "una vista plana de todas las cuentas". Descartada tras 2 iteraciones — con 6+ cuentas multi-divisa el dashboard se rompía.
  • Versión actual: agrupa por kind (current, savings, brokerage, pension, crypto) con badges de divisa nativa y columna fija de equivalente EUR.
  • Validación continua con time-to-balance (segundos hasta encontrar un saldo) + conversaciones con freelance multi-país, founder con 3 jurisdicciones y expat USD + EUR + GBP.
  • Cada release pasa por un check de SCA en flujos críticos — un fallo aquí no es UI, es regulatorio.

Decisiones de modelo de datos

  • Cuenta: saldo nativo + equivalente EUR + available + pending out + rate/yield + BIC/IBAN cuando aplica.
  • Tarjeta: network, kind, límite mensual, gasto mes en curso, freeze, contactless, online, withdraw, % rewards, tokenization (Apple/Google Pay).
  • Transacción: 15 categorías unificadas con Lifestyle, status (posted/pending/declined), country code y notas para reconciliación con el ledger.

Decisiones de UI

  • Tabla canónica con 3 modos (list, cards, chart) que comparten paginación.
  • Modales canónicos para "Manage card", "Send transfer" o "Convert FX": bottom-sheet con drag handle en móvil, centered card en desktop, focus trap, ESC, scroll-lock, safe-area-inset-bottom.
  • Flujos sensibles (transfer SWIFT, convert FX) confirman con el threshold de firma del usuario antes de ejecutar.

Cómo encaja con el resto del producto

  • Las transacciones del ledger aparecen en el activity feed cross-module del dashboard.
  • Goals (Lifestyle) enlaza a cuentas reales de Banking.
  • FX programados (T+1 SEPA Instant, T+2 SWIFT) aparecen como eventos en el calendar.
  • La reconciliación cross-cuenta es un job de Operations.

Decisiones de diseño

Tabla canónica con 3 modos de vista

List (densa, sort + filter por columna), cards (1/2/3 cols) y chart (bar chart SVG nativo que detecta columnas numéricas). Paginación compartida — el chart muestra la página actual.

Modales canónicos accesibles por defecto

Bottom-sheet con drag handle en móvil, centered card en desktop. Focus trap, ESC, scroll-lock y safe-area-inset-bottom respetado para no solapar con el home indicator de iOS.

Categorización unificada cross-módulo

15 categorías comunes compartidas por Banking, Budgets, Tax y Spending Insights. Una sola taxonomía evita que la misma compra aparezca como "Food" en un módulo y "Restaurants" en otro.

Wallet FX como first-class citizen

Las 8 divisas (EUR, USD, GBP, CHF, JPY, AUD, CAD, CNH) son tipos primarios del modelo, no extensiones de transferencias. Conversiones, hedges y exposición FX consolidada en el dashboard.

Pantallas

Vista de detalle del módulo Banking en producción.
Vista de detalle del módulo Banking en producción.
Modal canónico — variante centered desktop.
Modal canónico — variante centered desktop.

Retrospectiva honesta

Qué funcionó

  • Modelar Banking sobre la misma capa de transacciones que el resto del producto. Categorías compartidas y vistas guardadas son hoy una de las features más usadas en Lifestyle también.
  • La tabla canónica en 3 modos. Una sola implementación cubre 12 pantallas distintas del módulo y mantiene la consistencia visual sin código duplicado.
  • Modales como bottom-sheet en móvil y centered card en desktop. Cero quejas de usabilidad en iOS — el detalle del safe-area-inset-bottom evitó un bug típico con el home indicator.

Qué cambiaría

  • Habría documentado los modales canónicos en Storybook desde el primer sprint. Tardé en hacerlo y entre tanto reescribí el patrón dos veces.
  • El primer modelo de tarjetas no contemplaba virtuales con caducidad efímera. Hubo que rediseñar el lifecycle de la tarjeta virtual (issued → active → expired) en sprint 4.

Qué queda abierto

  • Integración con Open Banking PSD2 vía GoCardless BAD / Tink / Plaid para sustituir los datos mock por cuentas reales.
  • Soporte de Apple Pay / Google Pay como métodos de pago dentro de los modales de transfer y top-up.

¿Te interesa que aporte este nivel de detalle a tu equipo?

Estoy disponible para incorporarme en plantilla, contrato indefinido, 100 % remoto desde cualquier lugar del mundo (vivo en Madrid).

Siguiente proyecto

PortfolioMap · Investing: portfolios, mandates y crypto