¿Pueden las rutinas de Claude Code vigilar mis finanzas?
(driggsby.com)- Al conectar datos de cuentas financieras y conectores MCP, se pueden automatizar revisiones financieras repetitivas solo con prompts, usando saldos, historial de transacciones, inversiones e información de préstamos
- El enfoque anterior con Codex CLI cron-job se rompía con frecuencia por inicios de sesión web, problemas de renderizado en el navegador, 2FA y limitaciones de passkeys, lo que dificultaba mantener revisiones estables por cuenta
- La automatización renovada de correo diario combina una programación matutina, un conector personalizado y la herramienta
email_me()para enviar resúmenes de todas las cuentas y del patrimonio neto; además, el contenido puede cambiarse ajustando solo el prompt - La automatización de monitoreo de transacciones detecta movimientos anómalos y grandes salidas de dinero comparándolos con patrones recientes, y envía correos solo cuando se cumplen ciertas condiciones para reducir alertas innecesarias
- Este enfoque permite probar y escalar rápidamente automatización operativa personalizada a muy bajo costo, y hace posible que incluso personas no desarrolladoras manejen directamente revisiones financieras conectadas a datos en tiempo real
Cómo está armada la automatización
- Driggsby se conecta a cuentas financieras con Plaid y luego expone, mediante MCP, herramientas para saldos, historial de transacciones, inversiones e información de préstamos
- Al principio, el uso era principalmente interactivo, haciendo preguntas en Claude cuando hacía falta, pero empezaron a aparecer patrones repetitivos como revisar el patrimonio neto, verificar saldos y monitorear transacciones
- Claude Code routines facilitan automatizar este tipo de tareas repetitivas solo con prompts
- Puede funcionar con solo conectar prompts y conectores MCP, sin escribir bucles de agentes por separado ni preparar un entorno de despliegue
- Si los datos y herramientas pueden conectarse limpiamente mediante conectores MCP, entonces la automatización se vuelve posible
Limitaciones del enfoque anterior y el cambio
- Antes, todo estaba montado con un Codex CLI cron-job no interactivo que iniciaba sesión en cuentas bancarias, tarjetas de crédito, cuentas de corretaje y retiro para obtener saldos y transacciones recientes, y luego enviaba un correo diario con el resumen financiero
- Se usaba Chrome DevTools MCP para iniciar sesión en cada sitio web y extraer la información
- Era una tarea sencilla en teoría —enviar a la pareja un correo diario con el panorama financiero—, pero en la práctica fallaba seguido
- Era común que al día siguiente ya hubiera fallado, y por problemas de renderizado del navegador o solicitudes inesperadas de 2FA, la ejecución se detenía a nivel de cuenta
- A veces GPT cambiaba por completo el formato del correo o se confundía durante la ejecución y solo recuperaba información de una cuenta
- Entre las cuentas nuevas que había que añadir, algunas solo permitían inicio de sesión con passkey
- Por estas fallas repetidas, cada vez que no llegaba el correo esperado había que intervenir manualmente, y para hacer ese proceso menos estresante se terminó construyendo Driggsby
Automatización del correo diario
- Lo primero que se volvió a crear fue el correo diario, con el objetivo de recibir cada mañana un resumen claro de todas las cuentas y del patrimonio neto
- Esa información originalmente estaba en una hoja de cálculo vieja, perdida en algún lugar de Google Drive
- Actualizarla tomaba apenas unos 15 minutos, pero esa pequeña fricción hacía que casi nunca se actualizara, como mucho una vez cada seis meses
- En routines, la configuración inicial fue muy sencilla: bastó con el prompt, una programación por la mañana y la conexión del custom connector de Driggsby
- Sin embargo, al principio no había forma de enviar el correo, y al conectar Gmail connector solo se generaban borradores bien organizados
- Gmail connector no podía enviarlos realmente; solo crear drafts
- Para resolverlo, se añadió a Driggsby la herramienta MCP
email_me(), y este enfoque terminó funcionando bastante bien- El destinatario quedó restringido únicamente al correo verificado del propietario de la cuenta y se bloquearon enlaces e imágenes para mantener un nivel de seguridad aceptable
- Se forzó el cuerpo en Markdown y se añadió CSS al correo renderizado desde Markdown para reducir inconsistencias de formato entre ejecuciones
- Algunos bugs pequeños pudieron corregirse con relativa facilidad gracias a la inspectability de routines
- La UI se parece a una sesión normal de Claude Code en Claude Desktop o en la web, por lo que era fácil inspeccionar directamente el estado de la ejecución
- Tras las pruebas, el correo diario empezó a llegar de verdad, y luego fue posible cambiar su contenido ajustando solo el prompt desde la UI de routines, sin tocar código
- Como cada miembro de la pareja mira cosas distintas, también fue posible configurar correos diarios diferentes para cada persona con prompts separados
Monitoreo de transacciones anómalas y gastos
- Una vez establecido el correo diario, se empezó a sumar más automatización aprovechando que se podían levantar agentes sin la carga de operar infraestructura aparte
- Primero se configuró un sistema de monitoreo de transacciones anómalas usando datos de transacciones, con una routine semanal que cargaba un año de movimientos de la tarjeta Amex pero se enfocaba sobre todo en los últimos 7 días
- Si las transacciones de los últimos 7 días parecían inesperadas frente a patrones históricos —como cobros duplicados, cambios en suscripciones o nombres/descripciones de comercios desconocidos— se enviaba un correo
- Si las transacciones recientes eran normales y consistentes, no se enviaba ninguna alerta
- Este tipo de prompt sencillo puede generar false positives, pero parece tener un costo bajo tanto para ir refinándolo con el tiempo como para revisar los resultados
- Después se creó, para la cuenta corriente, una routine que vigila salidas de dinero grandes e inesperadas
- Revisa solo las transacciones del último día y busca, comparándolas con patrones de los últimos 12 meses, movimientos de más de $500 que representen salidas grandes o inusuales
- Como la automatización corre todos los días, el alcance de revisión se restringió deliberadamente solo al día más reciente
- Si encuentra algo que cumpla la condición, envía un correo con el asunto "Checking account outflow alert"; si no, no avisa
- Más adelante, este enfoque se extendió también a monitoreo de inversiones, análisis de suscripciones y vigilancia de varias categorías de gasto
- Como es muy fácil configurar todo con routines, con el tiempo aumenta la necesidad de agrupar varias condiciones a la vez o refinar mejor los prompts
Por qué importa
- La fortaleza central de routines es que permite probar casi sin esfuerzo
- Si se te ocurre un prompt, puedes poner en marcha la automatización de inmediato
- También destaca que incluso personas no desarrolladoras pueden manejar directamente automatizaciones en la nube conectadas a datos en vivo
- La esposa del autor, que es CPA, también usa los datos en tiempo real de Driggsby para ejecutar sus propias automatizaciones
- Este modo de uso permite crear rápidamente automatización operativa personalizada solo con prompts y conectores
1 comentarios
Comentarios de Hacker News
Hace poco armé algo así por mi cuenta. Sincronicé transacciones de cuenta corriente/tarjeta de crédito a Google Sheets con https://tiller.com/ y luego reflejé esa hoja de cálculo en una DB gratuita de Supabase usando GitHub Actions
Le permití a Claude/Codex acceder al historial de transacciones y saldos con consultas en inglés a través de Supabase MCP o psql, y me impresionó bastante su capacidad para detectar patrones de suscripción o patrones anómalos. En especial, el pronóstico de flujo de caja, que las herramientas online suelen hacer mal, estuvo bastante bien; por ejemplo, podía preguntarle cuánto podía mover a ahorros según mis patrones de gasto mensuales y el efectivo disponible
En la parte de clasificación automática, Claude manejó bastante bien un DSL personalizado. Le hice crear un conjunto de reglas en tablas markdown para normalizar beneficiarios/categorías, y esas reglas también corren junto con GitHub Actions
Quisiera saber si los trae mediante algo como Plaid, si todavía hay que entregar credenciales de banca web y cómo manejan el 2FA
También me preocupa si en las instituciones financieras sin API oficial siguen dependiendo de screen scraping, y qué pasa si por un bug hay clics o consentimientos no intencionales, o incluso una transferencia equivocada. Dicen que es de solo lectura, pero casi nunca he visto bancos que realmente ofrezcan cuentas auxiliares de solo lectura para banca personal
También me gustaría saber si tienen seguro o alguna garantía para que uno pueda ser compensado en caso de un daño financiero grande, y me preocupan las implicaciones de privacidad de mostrar todos mis datos bancarios a dos empresas. Escuché sobre demandas colectivas por venta o compartición inapropiada de datos, pero no sé qué pasó realmente
También me incomoda esa parte de los términos del banco donde aceptas no compartir tu contraseña con terceros. Me cuesta confiar mis finanzas a un servicio web/cloud; preferiría software cliente que corra localmente y se comunique con la API del banco. También me pregunto si hay algo así en Canadá
Dicen que viene open banking, pero tampoco está claro si se podrá acceder con software hecho por uno mismo. Si de verdad fuera confiable y además obligara políticas para minimizar la retención interna después de descargar los datos, yo también querría usar APIs bancarias
Lo uso desde que Mint fue adquirido por Intuit, y tengo una configuración parecida. Solo que yo conecté acceso a sheets con un modelo local de qwen y una API key creada con OAuth, aunque el enfoque de Claude Routine probablemente habría sido mucho más fácil
Me gustaría ver la configuración completa y, sobre todo, qué prompts usas
Tal vez porque mi patrimonio neto es bajo, pero sinceramente no veo por qué esto sería valioso
Tampoco quiero que un LLM me mande correos todos los días, y si necesito ver mis inversiones con más frecuencia que cada trimestre, probablemente debería moverme a inversiones más seguras. Tengo algo de interés en herramientas de presupuesto, pero me gustaría que fueran completamente deterministas
Mi planificación financiera suele ser bastante tranquila, así que creo que me conviene más buscar un trabajo con mejor sueldo que dedicar más tiempo a optimizar gastos
Siempre he pensado que cualquier cosa relacionada con números debería ser completamente determinista
Le mostré una DB SQLite a un LLM y le pedí que me dijera qué veía en las transacciones de los últimos 5 años; lo que detectó o me recordó fue impresionante. Pero no estoy seguro de que haya habido un valor práctico real que de verdad me hiciera cambiar algo
Voy a intentar que lo revise mensualmente por un tiempo, pero incluso solo con actualizar el presupuesto ya normalmente sé cómo va mi situación financiera, así que no sé cuánto me ayudará
Yo la uso para seguir mis tarjetas de crédito y cuentas corrientes, y si quieres incluso podrías conectar MCP ahí para analizar datos en un solo lugar
Vivo en Canadá y uso https://lunchmoney.app/ para seguimiento junto con integración de Plaid
Como tiene API, le hice escribir a un LLM un CLI, y gracias a eso un agente puede traer casi cualquier dato que necesite
Otra cosa que le hice hacer fue acumular reglas de etiquetado, y eso corre una vez al día con cron. A veces también le hago revisar las reglas para que cree nuevas para transacciones sin clasificar
Creo que el patrón de hacer que el LLM memorice el trabajo en un motor de reglas o en código es bastante bueno. Una vez que tienes aunque sea un CLI consultable, ya puedes pedirle casi cualquier cosa a un agente
Para quienes tengan interés, comparto el panorama general de nuestra configuración de infraestructura/seguridad
El backend y el CLI están en Rust con linting estricto, y la web app corre sobre Axum con conexión a Postgres vía sqlx
Las funciones financieras son de solo lectura. No hay herramientas de transferencias, pago de facturas ni envío de dinero, y tampoco se puede mover dinero desde la superficie de AI
En Plaid solo pedimos transacciones, inversiones y deudas; no pedimos auth/transfer/payment initiation, así que no recibimos números completos de cuenta ni números de ruta, solo la máscara básica de los últimos 4 dígitos
El usuario y la contraseña del banco no pasan por nosotros sino por Plaid Link, y nosotros solo conservamos el access token por institución
Los access tokens de Plaid se guardan en una DB separada detrás de un único servicio de custodia en Cloud Run. Se cifran al almacenarse con Cloud KMS, el broker llama a endpoints KMS de cifrado/descifrado, y el material de la clave raíz nunca sale del perímetro HSM de Google. Solo la cuenta de servicio del broker tiene permisos de cifrado/descifrado y la web app no tiene permiso de lectura sobre esa DB
En todas las llamadas de cifrado/descifrado pasamos el ID del ítem de Plaid como AAD para que no se pueda tomar el texto cifrado de un ítem y descifrarlo cambiándolo por el token de otro ítem
Cada servicio de Cloud Run corre con su propio ID de nube y rol de DB, y las llamadas internas entre servicios también se autentican con identity tokens de vida corta
La DB de producción no tiene IP pública, y los secretos no se guardan ni en el código fuente ni en las imágenes de contenedor, sino en almacenamiento administrado de secretos
El conector de AI usa OAuth 2.1 + PKCE y tiene scopes por usuario, revocables desde la UI. Todas las tool calls registran el nombre de la herramienta, argumentos saneados, cliente que llamó y la razón dada por el agente, para que se pueda ver qué pidió el LLM en nombre del usuario
La superficie de AI no tiene herramientas de fetch-URL, shell ni E/S genérica; solo devuelve datos financieros estructurados. La red, IAM y los grants de DB se administran con Terraform, y los cambios de infraestructura también solo se hacen por esa vía
El acceso a la infraestructura está controlado con 2FA y llaves de seguridad
Da la impresión de que entiendes al público lector de este sitio, y el hecho de haber diseñado la seguridad con cuidado en cada capa aumenta la confianza en toda la herramienta
Yo también había pensado en construir algo parecido; mi MVP inicial era algo como descargar manualmente PDFs de estados de cuenta y configurar con Claude un ledger para contabilidad en texto plano, con idea de conectar Plaid después
En particular, me da curiosidad cómo usa la gente Plaid. Quisiera saber si hace falta cierto nivel de usuarios para empezar, o si se puede crear una cuenta de Plaid para uso personal simplemente para conectar mis cuentas personales y de negocio a una API limpia
Hay que tener cuidado al usar Routine
Hay una nota muy pequeña que casi no se ve: en modo routine las herramientas MCP siempre quedan permitidas, incluyendo permisos de escritura. Así que técnicamente el agente podría modificar recursos por su cuenta
Esto parece una solución en busca de problema. https://tiller.com/ por sí solo ya funciona bastante bien, en la hoja de cálculo puedes hacer todos los cálculos que quieras y, de paso, no hay alucinaciones
Tampoco entiendo por qué querrías resúmenes larguísimos de un LLM para leer. Si solo clasificas tus gastos tú mismo de vez en cuando, las anomalías saltan a la vista rápidamente, y con Tiller eso además es fácil
En este espacio van a aparecer muchísimos productos distintos, y el nuestro es solo un enfoque entre varios. A mí también me gusta que haya más intentos así
Lo más importante es que un LLM puede absorber y combinar fácilmente múltiples fuentes de datos
En Era Finance estamos construyendo una solución exactamente para esto. Es Era Context, un MCP que conecta finanzas personales con cualquier agente compatible, y se puede ver en https://era.app
Por ahora estamos enfocados en herramientas de lectura, pero también estamos preparando herramientas de escritura para transferir dinero o pagar deudas
Si hay funciones que quieran ver, me gustaría pedirles que le escriban a alex en ese dominio. Como referencia, soy Alex, el CEO; casi es mi primera vez en HN, pero antes fui responsable de la presencia web de stripe.com y antes estuve en Square/CashApp
Puede que la batalla ya esté perdida, pero de verdad no entiendo por qué alguien querría darle su historial financiero completo a un LLM
No me parece que los proveedores de LLM tengan protecciones más fuertes para este tipo de datos que la industria financiera. Y la propia industria financiera ya es bastante dura en cuanto a recopilar, explotar y vender nuestros datos
Como me interesan los patrones de gasto y las inversiones, con prompts muy básicos ya he descubierto cosas que antes se me pasaban
Claro, hacer que esto sea seguro es extremadamente difícil, y por eso llevo muchísimo tiempo pensando en esa parte
Entonces no entiendo exactamente cuál sería el problema
Mi banco principal, el Monzo del Reino Unido, ofrece una API completa y webhooks trigger para eventos
Gracias a eso pude hacer un bot de WhatsApp que me pregunta por la razón cuando aparece una transacción inusual, y el LLM se usa solo para ese razonamiento. También tengo una automatización que barre el saldo a una cuenta de ahorro antes de medianoche todos los días para maximizar el interés diario
Mantengo solo una pequeña cantidad en la cuenta de uso diario, y si gasto dinero durante el día, luego lo repongo desde ahorros para mantener ese saldo bajo. Si necesito un gasto más grande, entonces sí transfiero manualmente
Cuando intenté usar Claude para analizar transacciones pasadas, seguía teniendo alucinaciones: inventaba cargos que no existían, agregaba ítems nuevos y hacía conteo duplicado
Para manejar finanzas no alcanza con que Claude acierte el 95%. Como siempre tengo que estar alerta y revisar los resultados, en mi caso básicamente deja de tener valor
Yo también siento que Claude tiene bastante tendencia a alucinar, especialmente con datasets incompletos o limitados