- Khi kết nối dữ liệu tài khoản tài chính và MCP connector, có thể tự động hóa các tác vụ kiểm tra tài chính lặp đi lặp lại chỉ bằng prompt, dựa trên số dư, lịch sử giao dịch, đầu tư và thông tin khoản vay
- Cách làm Codex CLI cron-job trước đây thường xuyên bị hỏng vì đăng nhập web, vấn đề render trình duyệt, 2FA và giới hạn passkey, nên rất khó duy trì việc kiểm tra ổn định cho từng tài khoản
- Hệ thống tự động gửi email hằng ngày được dựng lại kết hợp lịch buổi sáng, custom connector và công cụ
email_me() để tổng hợp toàn bộ tài khoản và giá trị tài sản ròng rồi gửi đi; chỉ cần chỉnh prompt là cũng có thể thay đổi nội dung
- Tự động hóa giám sát giao dịch có thể phát hiện giao dịch bất thường và dòng tiền ra lớn bằng cách so sánh với các mẫu gần đây, và được thiết lập để chỉ gửi email khi đúng điều kiện nhằm giảm các cảnh báo không cần thiết
- Cách làm này giúp tự động hóa vận hành theo nhu cầu cá nhân được thử nghiệm và mở rộng rất nhanh với chi phí cực thấp, đồng thời cho phép cả người không phải lập trình viên cũng trực tiếp xử lý việc kiểm tra tài chính gắn với dữ liệu thời gian thực
Cách cấu hình tự động hóa
- Driggsby kết nối tới các tài khoản tài chính bằng Plaid, sau đó thông qua MCP để phơi bày các công cụ như số dư, lịch sử giao dịch, thông tin đầu tư và thông tin khoản vay
- Ban đầu, trọng tâm là cách dùng hội thoại: đặt câu hỏi trong Claude khi cần, nhưng dần lộ ra những mẫu tác vụ lặp lại như kiểm tra tài sản ròng, rà soát số dư và theo dõi giao dịch
- Claude Code routines giúp tự động hóa các tác vụ lặp lại này chỉ bằng prompt
- Không cần viết mã agent loop riêng hay chuẩn bị môi trường triển khai; chỉ cần nối prompt với MCP connector là có thể chạy
- Nếu dữ liệu và công cụ được kết nối gọn gàng qua MCP connector thì có thể cấu hình tự động hóa
Giới hạn của cách cũ và bước chuyển đổi
- Trước đây, tác giả dùng Codex CLI cron-job chạy không tương tác để đăng nhập vào các tài khoản ngân hàng, thẻ tín dụng, chứng khoán và hưu trí, lấy số dư cùng giao dịch gần đây, rồi gửi email tổng quan tài chính hằng ngày
- Chrome DevTools MCP được dùng để đăng nhập vào từng website và trích xuất thông tin
- Dù chỉ là tác vụ đơn giản gửi email tổng quan tài chính hằng ngày cho hai vợ chồng, trên thực tế nó lại thường xuyên hỏng
- Việc thất bại ngay từ ngày hôm sau cứ lặp lại; do vấn đề render trình duyệt hoặc yêu cầu 2FA bất ngờ, tiến trình thường bị dừng ở cấp độ từng tài khoản
- Cũng có lúc GPT thay đổi hoàn toàn định dạng email, hoặc bị rối trong lúc chạy nên chỉ lấy thông tin của một tài khoản
- Trong số các tài khoản cần thêm mới, có những nơi chỉ cho phép đăng nhập bằng passkey
- Vì các lỗi lặp đi lặp lại này, cứ mỗi lần email mong đợi không đến là tác giả lại phải tự xử lý; để giảm căng thẳng của quy trình đó nên mới xây dựng Driggsby
Tự động gửi email hằng ngày
- Thứ đầu tiên được dựng lại là email hằng ngày, với mục tiêu là mỗi sáng nhận được bản tóm tắt toàn bộ tài khoản và tài sản ròng trong một định dạng gọn gàng
- Thông tin này vốn nằm trong một bảng tính cũ ở đâu đó trên Google Drive
- Việc cập nhật chỉ mất khoảng 15 phút, nhưng ma sát nhỏ đó vẫn khiến tác giả không cập nhật thường xuyên; nhiều nhất cũng chỉ khoảng 6 tháng một lần
- Trong routines, việc thiết lập ban đầu diễn ra rất dễ dàng chỉ với prompt đầu vào, lịch buổi sáng và kết nối Driggsby custom connector
- Tuy nhiên lúc đầu chưa có cách nào để gửi email, và khi gắn Gmail connector vào thì chỉ tạo ra các bản nháp được trình bày đẹp mắt
- Gmail connector không thể gửi thật mà chỉ tạo draft
- Để giải quyết, tác giả thêm công cụ MCP
email_me() vào Driggsby, và cách này hoạt động khá tiện lợi
- Người nhận bị giới hạn chỉ là email đã xác minh của chủ tài khoản, đồng thời chặn link và hình ảnh để đạt mức chấp nhận được về bảo mật
- Phần nội dung được bắt buộc ở dạng Markdown, rồi thêm CSS vào email render từ Markdown để giảm sự không nhất quán về định dạng phát sinh ở mỗi lần chạy
- Một vài lỗi nhỏ có thể sửa tương đối dễ nhờ khả năng inspectability của routines
- UI trông giống một phiên Claude Code thông thường trên Claude Desktop hoặc ứng dụng web, nên dễ trực tiếp kiểm tra trạng thái trong lúc chạy
- Sau khi thử nghiệm, email hằng ngày thực sự đã đến; từ đó về sau, việc thay đổi nội dung email cũng có thể thực hiện bằng cách chỉ chỉnh prompt trong UI routines mà không cần sửa mã
- Vì hai vợ chồng xem các hạng mục khác nhau, họ cũng có thể cấu hình các email hằng ngày khác nhau cho từng người bằng các prompt riêng biệt
Giám sát giao dịch bất thường và chi tiêu
- Sau khi email hằng ngày đi vào ổn định, tác giả bắt đầu gắn thêm nhiều tự động hóa hơn bằng cách tận dụng việc có thể khởi chạy agent mà không phải gánh thêm hạ tầng riêng
- Trước tiên là cấu hình giám sát giao dịch bất thường bằng dữ liệu giao dịch; trong routine chạy hằng tuần, hệ thống tải một năm giao dịch của thẻ tín dụng Amex nhưng được thiết lập để tập trung vào 7 ngày gần nhất
- Nếu các giao dịch trong 7 ngày gần đây có điều bất ngờ so với mẫu trong quá khứ, như bị tính tiền hai lần, thay đổi phí thuê bao, hay tên/mô tả đơn vị bán hàng lạ, thì sẽ gửi email
- Nếu các giao dịch 7 ngày gần đây là bình thường và nhất quán thì hệ thống được giới hạn để không gửi cảnh báo
- Những prompt đơn giản kiểu này có thể tạo ra false positive, nhưng chi phí tinh chỉnh theo thời gian và chi phí rà soát có vẻ vẫn thấp
- Tiếp đó, với tài khoản thanh toán, tác giả tạo một routine để giám sát các khoản tiền ra lớn ngoài dự kiến
- Chỉ xem xét các giao dịch của ngày gần nhất, và so sánh với mẫu của 12 tháng trước để tìm các giao dịch trên $500 là dòng tiền ra lớn hoặc bất thường
- Vì tự động hóa chạy mỗi ngày, phạm vi rà soát được giới hạn chặt chỉ trong một ngày gần đây
- Nếu có mục phù hợp điều kiện, hệ thống sẽ gửi email với tiêu đề "Checking account outflow alert"; nếu không có thì sẽ không thông báo
- Sau đó, cách làm này còn được mở rộng sang giám sát đầu tư, phân tích thuê bao và theo dõi nhiều hạng mục chi tiêu khác nhau
- Vì routines rất dễ thiết lập, về lâu dài nhu cầu gộp nhiều điều kiện cùng lúc hoặc tinh chỉnh prompt phức tạp hơn sẽ tăng lên
Vì sao điều này quan trọng
- Điểm mạnh cốt lõi của routines là có thể thử gần như không tốn công
- Nghĩ ra prompt là có thể lập tức chạy tự động hóa
- Một điểm nổi bật là ngay cả người không phải lập trình viên cũng có thể trực tiếp xử lý tự động hóa trên cloud gắn với dữ liệu live
- Người vợ/chồng là CPA của tác giả cũng đang tự kéo dữ liệu thời gian thực từ Driggsby và tự chạy các tự động hóa cho riêng mình
- Kiểu sử dụng này cho phép nhanh chóng tạo ra tự động hóa vận hành theo nhu cầu cá nhân chỉ với prompt và connector
1 bình luận
Ý kiến trên Hacker News
Gần đây tôi đã tự dựng theo kiểu này. Dùng https://tiller.com/ để đồng bộ giao dịch tài khoản thanh toán/thẻ tín dụng vào Google Sheets, rồi dùng GitHub Actions để mirror bảng tính đó sang DB Supabase miễn phí
Tôi cho Claude/Codex truy cập lịch sử giao dịch và số dư bằng truy vấn tiếng Anh qua Supabase MCP hoặc psql, và khả năng tìm ra các mẫu đăng ký định kỳ hay mẫu bất thường của nó khá ấn tượng. Đặc biệt, phần dự báo dòng tiền mà các công cụ trực tuyến thường làm chưa tốt cũng ổn, ví dụ có thể hỏi nên chuyển bao nhiêu sang tiết kiệm dựa trên mô hình chi tiêu hằng tháng và lượng tiền mặt khả dụng
Về phân loại tự động, Claude xử lý DSL tùy chỉnh khá tốt. Tôi đã để nó tạo một bộ quy tắc dạng bảng markdown để chuẩn hóa người nhận thanh toán/danh mục, và các quy tắc đó cũng chạy cùng trong GitHub Actions
Có phải nó kéo qua thứ như Plaid không, hay vẫn phải đưa thông tin đăng nhập web banking, và 2FA được xử lý ra sao
Với các tổ chức tài chính không có API chính thức thì có còn phải dựa vào screen scraping không, và nếu lỗi gây ra các cú nhấp hay chấp thuận ngoài ý muốn, thậm chí chuyển khoản nhầm, thì sẽ ra sao. Họ nói là chỉ đọc, nhưng tôi gần như chưa thấy ngân hàng nào trong mảng ngân hàng cá nhân thật sự hỗ trợ tài khoản phụ chỉ đọc
Tôi cũng muốn biết liệu có bảo hiểm hay bảo đảm nào để được bồi thường nếu xảy ra thiệt hại tài chính quy mô lớn không, và cũng lo về hệ quả quyền riêng tư khi phải cho hai công ty xem toàn bộ dữ liệu ngân hàng. Tôi có nghe nói đến các vụ kiện tập thể liên quan đến việc dữ liệu bị bán/chia sẻ không phù hợp, nhưng không rõ thực tế đã xảy ra chuyện gì
Tôi cũng ngại điều khoản trong thỏa thuận ngân hàng rằng mình đồng ý không chia sẻ mật khẩu với bên thứ ba. Giao tài chính của tôi cho một dịch vụ web/cloud vẫn rất khó chịu, và tôi thích phần mềm client chạy cục bộ rồi giao tiếp với API ngân hàng hơn. Cũng tò mò ở Canada có cái gì như vậy không
Người ta nói open banking sắp đến, nhưng vẫn chưa rõ có cho phép truy cập bằng phần mềm do cá nhân tự làm hay không. Nếu thật sự đáng tin và còn bắt buộc chính sách chỉ giữ tối thiểu dữ liệu sau khi tải xuống thì tôi cũng muốn dùng API ngân hàng
Tôi dùng Tiller từ sau khi Mint bị Intuit mua lại, và cũng có thiết lập tương tự. Chỉ là tôi gắn quyền truy cập sheets bằng model qwen chạy cục bộ và API key tạo bằng OAuth, nhưng cách Claude Routine chắc hẳn dễ hơn nhiều
Tôi muốn xem cách thiết lập tổng thể, đặc biệt là bạn dùng những prompt nào
Có lẽ vì giá trị tài sản ròng của tôi thấp, nhưng thành thật mà nói tôi không hiểu tại sao cái này lại có giá trị
Tôi cũng không muốn LLM gửi email mỗi ngày, và nếu tôi phải xem tình hình đầu tư thường xuyên hơn mỗi quý thì có lẽ tôi nên chọn kiểu đầu tư an toàn hơn. Tôi có hơi quan tâm tới công cụ quản lý ngân sách, nhưng tôi muốn thứ đó phải hoàn toàn có tính quyết định
Kế hoạch tài chính của tôi nhìn chung khá yên ổn, nên tôi nghĩ thay vì dành thêm thời gian tối ưu chi tiêu thì thà tìm công việc lương cao hơn còn hơn
Tôi vốn nghĩ những thứ liên quan đến con số phải hoàn toàn có tính quyết định
Tôi đã cho LLM xem DB SQLite và bảo nó nói thử những gì nó thấy từ các giao dịch 5 năm qua, và những điều nó phát hiện hay nhắc lại quả thật khá ấn tượng. Nhưng tôi không chắc có giá trị thực tế nào khiến tôi thực sự thay đổi điều gì không
Tôi sẽ thử để nó rà soát hằng tháng một thời gian, nhưng chỉ riêng việc cập nhật ngân sách thôi thì tôi cũng đã khá rõ tình hình tài chính của mình, nên chưa biết nó sẽ giúp được bao nhiêu
Tôi đang dùng nó để theo dõi thẻ tín dụng và tài khoản thanh toán, và nếu muốn thì cũng có thể nối MCP vào đó để phân tích dữ liệu tập trung ở một chỗ
Tôi sống ở Canada và đang dùng https://lunchmoney.app/ để theo dõi, cùng với tích hợp Plaid
Nó có API nên tôi đã bảo LLM viết một CLI, nhờ vậy agent có thể kéo gần như bất cứ dữ liệu nào nó cần
Một việc khác tôi giao là tích lũy các quy tắc gắn thẻ, và cái đó chạy bằng cron mỗi ngày một lần. Thỉnh thoảng tôi cho nó rà lại các quy tắc để tạo thêm quy tắc mới cho các giao dịch chưa phân loại
Tôi thấy mô hình bắt LLM ghi nhớ công việc thành engine quy tắc hoặc code khá hay. Một khi đã có CLI có thể truy vấn thì có thể giao cho agent gần như mọi thứ
Với những ai quan tâm, tôi sẽ chia sẻ bức tranh tổng quan về cấu hình hạ tầng/bảo mật của bên tôi
Backend và CLI là Rust được linting rất nghiêm ngặt, ứng dụng web chạy trên Axum và kết nối Postgres bằng sqlx
Các tính năng tài chính đều ở chế độ chỉ đọc. Không có công cụ chuyển tiền, thanh toán hóa đơn hay remit, và ở bề mặt AI cũng không thể di chuyển tiền
Với Plaid, chúng tôi chỉ yêu cầu giao dịch, đầu tư và nợ; không yêu cầu auth/transfer/payment initiation, nên không nhận số tài khoản đầy đủ hay routing number, chỉ nhận mask 4 số cuối cơ bản
Tên người dùng và mật khẩu ngân hàng không đi qua chúng tôi mà đi vào Plaid Link, còn chúng tôi chỉ giữ access token theo từng tổ chức
Plaid access token được để trong DB riêng phía sau một dịch vụ Cloud Run custody duy nhất. Khi lưu sẽ được mã hóa bằng Cloud KMS, broker gọi các endpoint encrypt/decrypt của KMS, và vật liệu khóa gốc không bao giờ rời khỏi ranh giới Google HSM. Chỉ service account của broker có quyền mã hóa/giải mã, còn webapp không có quyền đọc DB đó
Mọi lời gọi mã hóa/giải mã đều truyền Plaid item ID làm AAD để không thể lấy bản mã của item này rồi đổi sang token item khác để giải mã
Mỗi dịch vụ Cloud Run chạy với cloud ID và DB role riêng, và các lời gọi nội bộ giữa dịch vụ cũng được xác thực bằng identity token sống ngắn
DB vận hành không có public IP, và secret được đặt trong kho lưu trữ secret được quản lý chứ không nằm trong source hay image container
AI connector dùng OAuth 2.1 + PKCE và có scope theo từng người dùng, có thể revoke trong UI. Mọi tool call đều ghi lại tên công cụ, tham số đã làm sạch, client gọi, và lý do agent đưa ra, để có thể xem LLM đã yêu cầu gì thay mặt người dùng
Bề mặt AI không có công cụ fetch-URL, shell hay I/O tổng quát, mà chỉ trả về dữ liệu tài chính có cấu trúc. Networking, IAM và DB grant đều được quản lý bằng Terraform, và thay đổi hạ tầng cũng chỉ đi theo đường đó
Quyền truy cập hạ tầng được kiểm soát bằng 2FA và security key
Nó cho cảm giác bạn hiểu độc giả của trang này, và việc thiết kế bảo mật cẩn thận ở từng lớp cũng làm tăng niềm tin vào toàn bộ công cụ
Tôi cũng từng định tự làm thứ tương tự, nhưng MVP ban đầu chỉ ở mức tải thủ công PDF sao kê rồi dùng Claude để thiết lập ledger cho kế toán plain text, sau đó mới tính gắn Plaid
Tôi đặc biệt tò mò cách mọi người dùng Plaid. Muốn bắt đầu thì có cần một mức người dùng nhất định không, hay tôi có thể tạo tài khoản Plaid cho mục đích cá nhân chỉ để nối tài khoản cá nhân/doanh nghiệp của mình vào một API gọn gàng
Khi dùng Routine thì nên cẩn thận
Có một dòng hướng dẫn nhỏ gần như không ai để ý, rằng trong chế độ routine thì các công cụ MCP luôn được cho phép, bao gồm cả quyền ghi. Vì vậy về mặt kỹ thuật agent có thể tự ý thay đổi tài nguyên của bạn
Cái này giống như giải pháp đi tìm vấn đề. Chỉ riêng https://tiller.com/ cũng đã đủ tốt, trong spreadsheet bạn có thể làm mọi phép tính mình muốn, và thêm nữa là không có ảo giác
Tôi cũng không hiểu vì sao lại muốn một bản tóm tắt dài dòng do LLM tạo ra để rồi còn phải đọc. Chỉ cần tự phân loại chi tiêu thỉnh thoảng thì các điểm bất thường cũng hiện ra rất nhanh, và với Tiller thì việc đó cũng dễ
Sẽ có rất nhiều sản phẩm khác nhau xuất hiện trong lĩnh vực này, và sản phẩm của chúng tôi chỉ là một cách tiếp cận trong số đó. Tôi cũng thấy tốt khi có thêm nhiều thử nghiệm như vậy
Mấu chốt hơn là LLM có thể dễ dàng hấp thụ và kết hợp nhiều nguồn dữ liệu
Era Finance của chúng tôi đang xây đúng giải pháp cho việc này. Đó là Era Context, một MCP kết nối tài chính cá nhân với bất kỳ agent tương thích nào, có thể xem tại https://era.app
Hiện tại chúng tôi tập trung vào các công cụ đọc, nhưng cũng đang chuẩn bị công cụ ghi như chuyển tiền hay trả nợ
Nếu có tính năng nào bạn muốn thì hãy email cho alex ở domain trên. Nhân tiện, tôi là CEO Alex, gần như lần đầu lên HN, trước đây phụ trách web presence của stripe.com và trước đó làm ở Square/CashApp
Có lẽ trận này đã thua từ lâu rồi, nhưng tôi thật sự không hiểu vì sao ai đó lại muốn giao toàn bộ lịch sử giao dịch tài chính cho LLM
Tôi cũng không nghĩ các nhà cung cấp LLM lại có cơ chế bảo vệ dữ liệu kiểu này mạnh hơn ngành tài chính. Mà bản thân ngành tài chính vốn đã là một ngành khắc nghiệt trong việc thu thập, khai thác và bán dữ liệu của chúng ta rồi
Nếu bạn quan tâm đến mẫu chi tiêu hay đầu tư thì chỉ với những prompt rất cơ bản thôi, đôi khi tôi đã phát hiện ra những điều trước đây mình bỏ lỡ
Tất nhiên, để làm chuyện này an toàn là cực kỳ khó, nên tôi đã suy nghĩ rất lâu về phần đó
Vậy tôi không rõ chính xác vấn đề ở đây là gì
Ngân hàng chính của tôi là Monzo ở Anh, và họ cung cấp API đầy đủ cùng trigger webhook cho sự kiện
Nhờ vậy tôi đã làm một bot WhatsApp hỏi tôi giải thích lý do khi có giao dịch bất thường, còn LLM chỉ được dùng cho phần suy luận đó. Tôi cũng tự động hóa việc quét toàn bộ số dư trước nửa đêm mỗi ngày sang tài khoản tiết kiệm để tối đa hóa lãi theo ngày
Tôi chỉ giữ một ít tiền trong tài khoản chi tiêu hằng ngày, và nếu ban ngày có tiêu tiền thì lại bù từ tiết kiệm sang để duy trì số dư thấp đó. Khi cần chi khoản lớn hơn thì lúc đó tôi chuyển thủ công
Khi tôi thử dùng Claude để phân tích các giao dịch cũ, nó liên tục ảo giác kiểu tạo ra các khoản bị tính phí không tồn tại, thêm mục mới và đếm trùng
Khi làm việc với tài chính, việc Claude đúng 95% là không đủ. Bạn luôn phải cảnh giác và rà lại kết quả, nên trong trường hợp của tôi thì nó gần như không còn giá trị gì
Tôi cũng cảm thấy Claude khá dễ ảo giác, đặc biệt với các bộ dữ liệu không đầy đủ hoặc bị giới hạn