Comparación

BankBridge vs construir tu propio servidor MCP bancario

6 min read
Direct answer: Puedes construir el tuyo. Vas a necesitar una cuenta con un agregador bancario, OAuth 2.1 + PKCE + Dynamic Client Registration, cifrado AES-256-GCM para los tokens de acceso, un pipeline de consulta en vivo con clasificación de errores por banco y reintentos con espera exponencial, flujos de reconexión, facturación por cantidad en Stripe, un proceso de cancelación que no deje conexiones huérfanas generando comisiones de API, y una matriz de compatibilidad para 29 clientes MCP distintos. BankBridge hace todo eso por $5/mo por banco.

La idea de construirlo tú mismo

“Es solo MCP encima de la API de un agregador bancario, ¿qué tan difícil puede ser?” es el instinto correcto. La respuesta: no es difícil en lo conceptual, pero hay 8 piezas de nivel producción que tienes que hacer bien antes de que tu agente pueda responder de forma confiable “¿cuánto gasté en comida este mes?” sin mentir, sin fallar y sin filtrar los datos de otra persona. Aquí va cada una.

Cómo se ve el trabajo real

Recorre lo que BankBridge hace en cada consulta del agente. Esta es la lista de cosas que tendrías que implementar en una versión hecha por tu cuenta.

Autenticación: bearer + OAuth + PKCE + DCR

Para una configuración personal de una sola persona, un token bearer estático alcanza. Para una app de consumo donde cada usuario final conecta su propio banco, necesitas OAuth 2.1 con Dynamic Client Registration (RFC 7591) y PKCE. Eso significa: un endpoint de registro, un endpoint de autorización, un endpoint de tokens, rotación de tokens, manejo de refresh tokens y metadatos de descubrimiento en las dos rutas /.well-known/ que espera la especificación MCP. Ah, y cada cliente de agente (Claude.ai, Perplexity, VS Code Copilot) tiene sus propias particularidades sobre qué tipos de grant acepta.

Consulta en vivo + clasificación de errores

Una implementación ingenua guarda los datos bancarios en caché para que las llamadas a herramientas sean rápidas. Eso es un desastre de privacidad y de exactitud esperando a ocurrir: saldos viejos, listas de transacciones viejas, PII innecesaria en tus servidores. El patrón correcto es consultar en vivo en cada llamada.

Consultar en vivo significa que cada llamada tiene que clasificar los errores del proveedor en al menos cuatro categorías:

  • Requiere reautenticación: el banco pide volver a iniciar sesión (normalmente cada trimestre). No es fatal; las demás conexiones siguen devolviendo datos. Devuelve una advertencia estructurada con una URL de reautenticación.
  • Marcar como muerta: la conexión está rota de forma permanente. Márcala para el cron de reconciliación nocturno; devuelve resultados limpios de los demás bancos.
  • Reintentar: falla transitoria del proveedor. Espera exponencial (nosotros hacemos 3 intentos, 200ms → 600ms → 1800ms) antes de mostrar el error.
  • Omitir en silencio: timeout por llamada para uno de N bancos. Agrégalo al arreglo de advertencias, no lo muestres como error.

Además, un techo de timeout (usamos 15s en el cliente HTTP + 7s por herramienta) para que un banco colgado no pueda trabar una llamada de herramienta del agente.

Facturación + cancelación segura

Cada banco conectado te cuesta comisiones del agregador, así que necesitas precios por banco. Cantidad de la suscripción de Stripe = número de bancos, con prorrateo al agregar (a mitad de período) y sin prorrateo al quitar (a fin de período, para no chocar con el piso de cargo mínimo de $0.50 de Stripe).

La parte difícil es la fuga en la cancelación: cuando un usuario cancela, hay que eliminar cada conexión bancaria, o el agregador te sigue cobrando. Nuestra defensa de seis capas: manejador de webhooks, guardia al sincronizar, guardia en MCP, cron de reconciliación nocturno, ruta de reintento ante pagos fallidos y un registro de auditoría de cada eliminación. Cualquiera de las defensas atrapa la mayoría de los casos; las seis juntas garantizan cero fuga.

Matriz de compatibilidad de 29 hosts

Cada host que habla MCP tiene su propio flujo de instalación, su propio esquema de deeplinks (Cursor, VS Code, LM Studio, Warp), sus propios casos límite de OAuth (Claude.ai, Perplexity) y sus propios timeouts por defecto. Tienes que mantener una página de documentación por host, prellenar las claves de los usuarios en los fragmentos y mantener los fragmentos al día cuando los hosts cambian sus esquemas de configuración (lo hacen, cada pocos meses).

Hoy tenemos 29 integraciones de hosts. Incluso si solo te importan Claude y ChatGPT, eso son siete productos entre los dos (Code, Desktop, web, Cowork, ChatGPT, Apps SDK, Enterprise) con siete flujos de instalación.

Las cuentas del costo

El acceso al agregador cuesta $0.30–$0.60 por banco al mes para Transactions, más $1–$2 por banco al mes para Investments. El hosting de un despliegue de un solo usuario ronda los $5/mo. Gastarías un fin de semana de ingeniería en el esqueleto del servidor MCP y otro en OAuth. Después, cada mes o dos, gastarías un día arreglando compatibilidad con hosts, actualizando el SDK del agregador o parchando un caso límite de la consulta en vivo.

Si valoras tu tiempo de ingeniería aunque sea a $75 la hora, el punto de equilibrio contra los $5/mo de BankBridge cae más o menos en “una hora de mantenimiento al mes”. No vas a quedarte por debajo de eso.

Cuándo SÍ tiene sentido construirlo tú mismo

  • Necesitas una función que BankBridge no ofrece (mover dinero, un banco que no está en la lista de nuestro agregador, clasificación de datos a medida).
  • Estás construyendo un producto de consumo que compite con BankBridge y el precio de $5/mo sería tu propio margen.
  • Tienes requisitos estrictos de cumplimiento (HIPAA, SOC 2 Type II para un cliente específico) que exigen ser dueño de la infraestructura de punta a punta.
  • De verdad disfrutas mantener este tipo de plomería. No tiene nada de malo.

Para todos los demás (desarrolladores independientes, fundadores indie, fanáticos de las finanzas personales, equipos pequeños de operaciones), las cuentas y el tiempo no están a tu favor. Paga los $5.

FAQ

¿Podría usar directamente la API del agregador bancario?

Claro. Aun así tendrías que escribir la capa del protocolo MCP, operar tu propio servidor, manejar OAuth + PKCE + DCR para apps multiusuario, cifrar los tokens de acceso, clasificar los errores en las categorías que espera el formato de respuesta de MCP y mantener todo frente a 29 clientes host que no dejan de cambiar. La mayoría se detiene alrededor del paso 4.

¿BankBridge es de código abierto?

No. Las integraciones de cliente (el plugin de Claude Code, el paquete .mcpb, el repositorio de skills) son públicas; el servidor es de código cerrado. Así sostenemos el desarrollo de un producto de $5/mo.

¿Y si BankBridge desaparece?

Cancelas y eliminas los tokens de acceso cifrados de nuestra base de datos. Tus conexiones bancarias viven del lado del banco; tus cuentas siguen siendo tuyas. Nos comprometimos a avisar con 12 meses de anticipación si algún día cerramos.

¿Puedo alojar BankBridge en mi propio servidor?

Por ahora no. Podríamos ofrecer un nivel con licencia para autoalojarlo si hay suficiente demanda. Escríbenos a hello@greatwork.company si eso te haría decidirte.