¿Las rutinas de Claude Code pueden vigilar mis finanzas?
(driggsby.com)- Al conectar datos financieros mediante integración con Plaid como herramientas MCP, ahora es posible manejar saldos, transacciones, inversiones e información de préstamos, y automatizar las revisiones financieras repetitivas con Claude Code routines
- La automatización anterior del navegador basada en cron se rompía con frecuencia por problemas de renderizado, prompts de 2FA, errores que solo recopilaban algunas cuentas, cambios en el formato del correo y restricciones por passkeys, y para reducir eso se creó Driggsby
- El correo diario de resumen financiero se armó solo con un prompt, una hora de ejecución y el custom connector de Driggsby; como el conector de Gmail solo podía crear borradores, se añadió la herramienta
email_me()para resolver el envío real y estabilizar el formato - Con el mismo enfoque también se automatizó la detección de anomalías en transacciones de Amex de los últimos 7 días y la vigilancia de grandes salidas de dinero por encima de $500 en la checking account, configurando que no se envíen alertas cuando todo esté normal
- Como la carga de configuración y depuración es baja, incluso fue posible operar rutinas financieras personalizadas por separado para cada cónyuge, creando una base de automatización que se expande rápido hacia inversiones, suscripciones y monitoreo de gastos
Punto de partida de la automatización y estructura de Driggsby
- Antes, todo comenzaba con un trabajo diario de cron que ejecutaba Codex CLI y Chrome DevTools MCP de forma no interactiva para iniciar sesión en bancos, tarjetas y cuentas de corretaje o retiro, obtener saldos y transacciones recientes, y enviar por correo un resumen financiero diario a la pareja
- El primer día funcionó bastante bien, pero al día siguiente volvía a romperse
- Se acumulaban problemas: renderizado del navegador, prompts de 2FA inesperados, confusión durante la ejecución que hacía que solo se recuperaran algunas cuentas, cambios arbitrarios en el formato del correo y hasta la incorporación de cuentas que solo permitían passkeys
- Para reducir esa inestabilidad se creó Driggsby, y tras dos meses, 75k líneas de código en Rust y un contrato con Plaid, se llegó a la forma actual
- Driggsby se conecta a cuentas financieras con Plaid y luego expone, vía MCP, herramientas separadas para saldos, transacciones, información de inversiones, información de préstamos y más
- Al principio, Claude se abría cada vez que hacía falta para hacer preguntas financieras y recibir respuestas con Driggsby, pero con el tiempo se hizo evidente un patrón de consultas repetitivas, como revisar patrimonio neto, saldos y transacciones, o monitorear inversiones
Lo que cambió con Routines
- Las Claude Code routines, publicadas hace unos días, facilitan pasar este tipo de consultas repetitivas al piloto automático
- El loop de agentes ejecutándose en la nube no es algo nuevo, pero lo que destaca en routines es lo simple que resulta el proceso de configuración
- No hace falta escribir código para un loop de agentes aparte ni decidir dónde desplegarlo
- Tampoco es necesario levantar por cuenta propia entornos de ejecución como OpenClaw, Codex SDK o
claude -pen Hetzner
- Basta con escribir el prompt y conectar de forma limpia los datos y las herramientas mediante un MCP connector para montar la automatización de inmediato
Automatización del correo diario
-
Reemplazo de la vieja hoja de cálculo
- El primer problema que se retomó fue el correo diario, y el objetivo era recibir un mail resumen, limpio y fácil de leer, con todas las cuentas y el patrimonio neto de un vistazo
- Esa información había vivido por mucho tiempo en una vieja hoja de cálculo perdida en algún lugar de Google Drive, y aunque actualizarla tomaba apenas unos 15 minutos, esa pequeña fricción bastaba para no hacerlo seguido
- En la práctica, la frecuencia de actualización se quedaba, como mucho, en una vez cada 6 meses
-
Proceso de configuración de la rutina
- La configuración terminaba solo con ingresar el prompt, programar la hora de ejecución cada mañana, conectar el custom connector de Driggsby y guardar
- Pero al principio apareció un bloqueo inmediato: no había forma de enviar el correo
-
Límites del conector de Gmail y herramienta alternativa
- Al agregar el conector de Gmail, se generó un correo atractivo y con mucha densidad de información, pero en realidad solo se creaba como borrador en vez de llegar a la bandeja de entrada
- Como el conector de Gmail no podía enviar correos y solo permitía crear drafts, hacía falta otro método
- Después de revisar la tienda de conectores de Claude y no encontrar una forma de envío realmente cómoda, se añadió a Driggsby una herramienta MCP simple llamada
email_me()
-
Restricciones de email_me() y estabilización del formato
email_me()limita el destino de envío únicamente a la dirección de correo verificada del propietario de la cuenta, y además bloquea enlaces e imágenes para mantenerlo en un nivel aceptable desde el punto de vista de seguridad- Para reducir las variaciones de formato entre ejecuciones, se hizo obligatorio que el cuerpo del correo se recibiera en Markdown, y también se añadió CSS para correos renderizados desde Markdown
-
Depuración y resultado final
- Algunos bugs pequeños se corrigieron rápido porque routines permite inspeccionar fácilmente el proceso de ejecución
- La UI es casi igual a una sesión normal de Claude Code en Claude Desktop o la app web, así que resulta fácil revisar la rutina en ejecución tal como está
- Tras unas cuantas pruebas, el correo de las 7:47 a. m. realmente llegó y el problema del correo diario quedó resuelto
- Después de eso, cambiar el contenido del correo ya fue posible ajustando solo el prompt en la UI de routines, sin modificar código
-
Personalización individual para cada cónyuge
- La pareja también terminó teniendo su propio correo diario personal, editable con su propio prompt
- Como cada uno considera importantes cosas distintas, ahora es posible personalizar por separado la información que quieren recibir cada día
Expansión después del correo diario
-
Detección de anomalías en transacciones de tarjeta de los últimos 7 días
- Una vez establecido el correo diario, la atención pasó de la infraestructura a pensar qué más se podía hacer, ya que era posible lanzar nuevos agentes sin casi costo operativo
- Como los datos de transacciones ya estaban en Driggsby, la siguiente automatización fue la detección de anomalías en transacciones de la tarjeta de crédito Amex
- Se creó una routine de ejecución semanal y se configuró con el siguiente prompt
- Prompt de ejemplo original
- Recupera las transacciones de la tarjeta de crédito Amex del último año
- Separa solo las transacciones de los últimos 7 días y concentra la revisión en ese tramo
- Si en esos últimos 7 días hay cargos duplicados, cambios en cobros de suscripciones o elementos inesperados como nombres o descripciones extrañas de comercios al compararlos con patrones históricos, envía un correo
- Si todas las transacciones parecen normales y coinciden con los patrones anteriores, no envía ninguna alerta
- Un prompt tan simple puede producir false positives, pero es fácil refinarlo con el tiempo y también es bajo el costo de revisar los resultados
-
Vigilancia de grandes salidas de dinero en la checking account
- Después de eso, se creó una rutina para verificar si hubo una salida inesperada de fondos grandes desde la checking account
- El prompt se armó con las siguientes condiciones
- Prompt de ejemplo original
- Revisa las transacciones de la checking account y confirma, comparando con 12 meses de historial, si durante el último día hubo una gran salida de dinero que no encaje con patrones previos
- Se enfoca en transacciones mayores a $500
- Como esta automatización corre diariamente, se impone de forma deliberada la restricción de revisar solo las transacciones del último día
- Si encuentra elementos que cumplan la condición, envía un correo con el título "Checking account outflow alert"; si no, no avisa nada
-
Alcance de expansión adicional
- Con el tiempo, este flujo se fue extendiendo a inversiones, análisis de suscripciones y monitoreo de distintas categorías de gasto
- Configurarlo con routines es tan fácil que, hacia adelante, aumentará la necesidad de agrupar varias condiciones a la vez o refinar más cuidadosamente los prompts
Por qué importa
- El punto más fuerte de routines está en la automatización que se puede probar de inmediato con un esfuerzo casi nulo
- La barrera de entrada baja tanto que, si se te ocurre un prompt, ya estás cerca de poder poner en marcha una automatización
- Incluso la pareja, que es CPA, ya está ejecutando sus propias automatizaciones en la nube basadas en datos obtenidos en tiempo real desde Driggsby
- Esto empuja más hacia crear herramientas que permitan a cada persona conectar sus propios datos y construir automatizaciones fácilmente
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