- Dữ liệu tài chính tích hợp Plaid có thể được kết nối qua công cụ MCP để xử lý số dư, giao dịch, đầu tư và thông tin khoản vay, đồng thời tự động hóa các lần kiểm tra tài chính lặp đi lặp lại bằng Claude Code routines
- Tự động hóa trình duyệt dựa trên cron trước đây thường xuyên bị hỏng do lỗi render, lời nhắc 2FA, lỗi chỉ thu thập được một phần tài khoản, thay đổi định dạng email và hạn chế của passkey, và để giảm tình trạng này, Driggsby đã được tạo ra
- Email tóm tắt tài chính hằng ngày chỉ được cấu thành từ prompt, thời gian chạy và Driggsby custom connector; do Gmail connector chỉ có thể tạo bản nháp nên công cụ
email_me() đã được thêm vào để giải quyết việc gửi thật và ổn định định dạng
- Theo cách tương tự, tác vụ phát hiện bất thường trong giao dịch Amex 7 ngày gần nhất và giám sát các dòng tiền ra lớn vượt quá $500 trong checking account cũng được tự động hóa, và được thiết lập để không gửi cảnh báo khi mọi thứ bình thường
- Gánh nặng cấu hình và gỡ lỗi thấp đến mức có thể vận hành riêng cả routine tài chính được cá nhân hóa cho từng vợ chồng, và đây trở thành nền tảng tự động hóa có thể nhanh chóng mở rộng sang giám sát đầu tư, đăng ký và chi tiêu
Điểm khởi đầu của tự động hóa và cấu hình Driggsby
- Trước đây, quy trình bắt đầu bằng một tác vụ cron hằng ngày chạy Codex CLI và Chrome DevTools MCP ở chế độ không hội thoại để đăng nhập vào ngân hàng, thẻ, tài khoản 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 cho hai vợ chồng
- Ngày đầu tiên chạy khá ổn, nhưng sang ngày hôm sau lại tiếp tục bị hỏng
- Các vấn đề chồng chất gồm lỗi render trình duyệt, lời nhắc 2FA bất ngờ, việc chỉ lấy được một phần tài khoản do lẫn lộn trong lúc chạy, định dạng email bị thay đổi ngẫu nhiên, và cả việc phải thêm các tài khoản chỉ cho phép passkey
- Để giảm sự bất ổn này, Driggsby đã được tạo ra, và sau hai tháng với 75k dòng mã Rust cùng hợp đồng Plaid, nó đã đạt đến hình thái hiện tại
- Driggsby kết nối với các tài khoản tài chính bằng Plaid, sau đó thông qua MCP để lộ số dư, giao dịch, thông tin đầu tư và thông tin khoản vay dưới dạng các công cụ riêng biệt
- Ban đầu, mỗi khi cần thì chỉ mở Claude, đặt câu hỏi tài chính và nhận câu trả lời qua Driggsby; theo thời gian, các mẫu câu hỏi lặp lại như kiểm tra tài sản ròng, số dư, giao dịch và giám sát đầu tư dần lộ rõ
Routines đã thay đổi điều gì
- Claude Code routines được công bố vài ngày trước đã giúp dễ dàng chuyển các truy vấn lặp lại như vậy sang chế độ tự động điều khiển
- Bản thân vòng lặp tác nhân chạy trên đám mây không phải điều mới, nhưng routines nổi bật ở chỗ quá trình thiết lập cực kỳ đơn giản
- Không cần tự viết mã cho vòng lặp tác nhân riêng hay quyết định nơi triển khai
- Cũng không cần tự dựng các môi trường thực thi như OpenClaw, Codex SDK hay
claude -p trên Hetzner
- Chỉ cần viết prompt, rồi kết nối dữ liệu và công cụ gọn gàng bằng MCP connector là có thể lập tức cấu hình tự động hóa
Tự động hóa email hằng ngày
-
Thay thế bảng tính cũ
- Vấn đề được khởi động lại đầu tiên là email hằng ngày, với mục tiêu nhận được một email tóm tắt gọn gàng để nhìn toàn bộ tài khoản và tài sản ròng trong nháy mắt
- Thông tin này từ lâu đã nằm trong một bảng tính cũ đâu đó trên Google Drive, và dù việc cập nhật chỉ mất khoảng 15 phút, ma sát nhỏ ấy vẫn đủ khiến nó không được cập nhật thường xuyên
- Trên thực tế, tần suất cập nhật nhiều nhất cũng chỉ khoảng 6 tháng một lần
-
Quy trình thiết lập routine
- Việc thiết lập kết thúc chỉ bằng cách nhập prompt, đặt lịch thời gian chạy mỗi sáng, kết nối Driggsby custom connector rồi lưu lại
- Tuy vậy, lúc đầu lại vấp ngay vì không có cách nào để gửi email
-
Giới hạn của Gmail connector và công cụ thay thế
- Khi thêm Gmail connector, một email đẹp mắt với mật độ thông tin cao được tạo ra, nhưng thực tế nó chỉ xuất hiện dưới dạng bản nháp thay vì vào hộp thư đến
- Vì Gmail connector không thể gửi email mà chỉ tạo draft, nên cần một cách khác
- Sau khi xem qua Claude connector store mà vẫn không thấy cách gửi nào đủ tiện, một công cụ MCP đơn giản tên
email_me() đã được thêm vào Driggsby
-
Ràng buộc của email_me() và ổn định định dạng
email_me() giới hạn đối tượng nhận chỉ còn địa chỉ email đã được xác minh của chủ tài khoản, đồng thời chặn liên kết và hình ảnh để đạt mức chấp nhận được về bảo mật- Để giảm tình trạng định dạng thay đổi giữa các lần chạy, nội dung email được yêu cầu bắt buộc là Markdown, và CSS dành cho email render Markdown cũng được thêm vào
-
Gỡ lỗi và kết quả cuối cùng
- Một vài lỗi nhỏ được sửa rất nhanh vì có thể dễ dàng quan sát quá trình thực thi của routines
- Giao diện gần như giống hệt một phiên Claude Code thông thường trong Claude Desktop hoặc ứng dụng web, nên rất dễ kiểm tra routine đang chạy
- Sau vài lần thử, email lúc 7:47 sáng đã thực sự đến nơi, và vấn đề email hằng ngày được giải quyết
- Sau đó, có thể thay đổi nội dung email chỉ bằng cách chỉnh prompt trong giao diện routines mà không cần sửa mã
-
Tùy biến riêng cho từng người trong vợ chồng
- Người bạn đời cũng có email hằng ngày cá nhân riêng để tự chỉnh bằng prompt của mình
- Vì mỗi người coi trọng các hạng mục khác nhau, giờ đây có thể tùy chỉnh riêng thông tin muốn nhận mỗi ngày
Mở rộng sau email hằng ngày
-
Phát hiện bất thường trong giao dịch thẻ 7 ngày gần nhất
- Sau khi email hằng ngày đã đi vào ổn định, sự chú ý chuyển sang việc còn có thể làm gì nữa, vì giờ có thể tiếp tục dựng các agent mới mà gần như không có gánh nặng hạ tầng
- Do dữ liệu giao dịch đã có sẵn trong Driggsby, bước tự động hóa tiếp theo là phát hiện bất thường trong giao dịch thẻ tín dụng Amex
- Một routine chạy hằng tuần được tạo ra và cấu hình bằng prompt bên dưới
- Prompt ví dụ trong bài gốc
- Lấy các giao dịch thẻ tín dụng Amex của 1 năm qua
- Tách riêng các giao dịch của 7 ngày cuối cùng để chỉ tập trung rà soát khoảng này
- So sánh với các mẫu trong quá khứ, nếu trong 7 ngày cuối có mục bất ngờ như tính phí trùng, thay đổi phí đăng ký, tên hoặc mô tả người bán lạ thì gửi email
- Nếu mọi giao dịch đều bình thường và khớp với mẫu trong quá khứ thì không gửi cảnh báo
- Một prompt đơn giản ở mức này có thể tạo ra false positive, nhưng theo thời gian rất dễ tinh chỉnh và chi phí xem lại kết quả cũng thấp
-
Giám sát dòng tiền ra lớn từ checking account
- Tiếp theo là một routine để kiểm tra xem có dòng tiền ra lớn bất ngờ nào từ checking account hay không
- Prompt được cấu thành theo các điều kiện dưới đây
- Prompt ví dụ trong bài gốc
- Xem xét các giao dịch của checking account, nhưng so sánh với dữ liệu giao dịch 12 tháng gần nhất để kiểm tra xem trong ngày cuối cùng có dòng tiền ra lớn nào không khớp với mẫu quá khứ hay không
- Tập trung vào các giao dịch vượt quá $500
- Vì tự động hóa này chạy mỗi ngày nên ràng buộc chỉ xem giao dịch của ngày cuối cùng được đặt khá chặt
- Nếu có mục phù hợp điều kiện, gửi email với tiêu đề "Checking account outflow alert", nếu không thì không thông báo
-
Phạm vi mở rộng thêm
- Theo thời gian, luồng này được mở rộng sang đầu tư, phân tích đăng ký, và giám sát nhiều hạng mục chi tiêu khác nhau
- Việc thiết lập bằng routines gần như dễ đến mức hơi quá, nên về sau nhu cầu gộp nhiều điều kiện cùng lúc hoặc tinh chỉnh prompt chi tiết hơn sẽ ngày càng lớn
Vì sao điều này quan trọng
- Điểm mạnh nhất của routines nằm ở tự động hóa có thể thử ngay lập tức gần như không cần tốn công
- Chỉ cần nảy ra prompt là rào cản gia nhập đã thấp đến mức có thể đem tự động hóa vào chạy
- Người bạn đời là CPA cũng đang tự chạy các tác vụ tự động hóa của mình trên đám mây dựa trên dữ liệu lấy theo thời gian thực từ Driggsby
- Điều này khiến trọng tâm nghiêng nhiều hơn về việc tạo ra thêm các công cụ giúp mỗi người dễ dàng kết nối dữ liệu của mình và tự xây các tự động hóa theo cách tương tự
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