- वित्तीय खाता डेटा और MCP connectors को जोड़ने पर बैलेंस, लेनदेन इतिहास, निवेश और लोन जानकारी के आधार पर बार-बार होने वाली वित्तीय जांच को सिर्फ prompts के जरिए ऑटोमेट किया जा सकता है
- पहले का Codex CLI cron-job तरीका web login, browser rendering समस्याओं, 2FA और passkey सीमाओं की वजह से अक्सर टूट जाता था, इसलिए हर खाते की निगरानी को स्थिर रूप से जारी रखना मुश्किल था
- दोबारा बनाया गया daily email automation सुबह के schedule, custom connector और
email_me()टूल को जोड़कर सभी खातों और net worth का सार भेजने के लिए तैयार किया गया, और prompt बदलकर उसकी सामग्री भी बदली जा सकती है - लेनदेन मॉनिटरिंग automation असामान्य लेनदेन और बड़े outflow को हाल के पैटर्न से तुलना करके पहचानती है, और केवल शर्तें पूरी होने पर email भेजती है ताकि अनावश्यक alerts कम हों
- यह तरीका व्यक्तिगत अनुकूल operational automation को बहुत कम लागत पर जल्दी टेस्ट और विस्तार करने देता है, और real-time data से जुड़ी वित्तीय जांच को non-developers के लिए भी सीधे इस्तेमाल योग्य बनाता है
automation को कॉन्फ़िगर करने का तरीका
- Driggsby Plaid के जरिए वित्तीय खातों से जुड़ने के बाद MCP के माध्यम से बैलेंस, लेनदेन इतिहास, निवेश जानकारी और लोन जानकारी जैसे टूल एक्सपोज़ करता है
- शुरुआत में Claude में ज़रूरत पड़ने पर सवाल पूछने वाला interactive usage मुख्य था, लेकिन net worth जांच, बैलेंस समीक्षा और transaction monitoring जैसे दोहराए जाने वाले पैटर्न सामने आए
- Claude Code routines ऐसे दोहराए जाने वाले कामों को सिर्फ prompts से ऑटोमेट करना आसान बनाती हैं
- अलग से agent loop code लिखे बिना या deployment environment तैयार किए बिना, सिर्फ prompt और MCP connector जोड़कर इसे चलाया जा सकता है
- अगर data और tools को MCP connector के जरिए साफ-सुथरे ढंग से जोड़ा जा सके, तो automation बनाना संभव हो जाता है
पुराने तरीके की सीमाएँ और बदलाव
- पहले non-interactive Codex CLI cron-job के जरिए bank, credit card, brokerage और retirement खातों में login करके बैलेंस और हाल के लेनदेन लाए जाते थे, और रोज़ाना financial summary email भेजी जाती थी
- Chrome DevTools MCP का उपयोग करके हर वेबसाइट में login और जानकारी extract की जाती थी
- यह पति-पत्नी को daily financial summary email भेजने का एक साधारण काम था, लेकिन व्यवहार में यह अक्सर टूट जाता था
- अगले ही दिन फेल हो जाना बार-बार होने लगा, और browser rendering समस्याओं या अप्रत्याशित 2FA request की वजह से अक्सर खाते के स्तर पर प्रक्रिया रुक जाती थी
- कभी GPT email का format पूरी तरह बदल देता था, या चलने के दौरान उलझकर सिर्फ एक खाते की जानकारी लाता था
- कुछ नए जोड़े जाने वाले खातों में सिर्फ passkey login की अनुमति थी
- इन बार-बार की रुकावटों की वजह से जब भी अपेक्षित email नहीं आता था, तो खुद हस्तक्षेप करना पड़ता था, और इसी प्रक्रिया को कम तनावपूर्ण बनाने के लिए Driggsby बनाया गया
daily email automation
- सबसे पहले दोबारा बनाया गया हिस्सा daily email था, और लक्ष्य था कि हर सुबह सभी खातों और net worth का साफ़-सुथरा सार मिले
- यह जानकारी पहले Google Drive में कहीं पड़ी एक पुरानी spreadsheet में थी
- उसे अपडेट करने में केवल लगभग 15 मिनट लगते थे, लेकिन उसी छोटी friction की वजह से उसे अक्सर अपडेट नहीं किया जाता था, और ज़्यादा से ज़्यादा 6 महीने में एक बार ही अपडेट होता था
- routines में prompt input, morning schedule सेट करना और Driggsby custom connector जोड़ना भर था, इसलिए शुरुआती setup बहुत आसान रहा
- लेकिन शुरुआत में email भेजने का कोई तरीका नहीं था, और Gmail connector जोड़ने पर सिर्फ अच्छी तरह व्यवस्थित draft बनता था
- Gmail connector असल में send नहीं कर सकता था, केवल draft बना सकता था
- इसे हल करने के लिए Driggsby में
email_me()MCP tool जोड़ा गया, और यह तरीका काफ़ी सुविधाजनक निकला- भेजने के लक्ष्य को केवल account owner के verified email तक सीमित किया गया और links व images को ब्लॉक किया गया, ताकि सुरक्षा के लिहाज़ से इसे स्वीकार्य स्तर पर रखा जा सके
- body को Markdown में मजबूर किया गया, और Markdown-rendering email में CSS जोड़कर हर run में होने वाली formatting असमानता को कम किया गया
- कुछ छोटे bugs को routines की inspectability की वजह से अपेक्षाकृत आसानी से ठीक किया जा सका
- UI, Claude Desktop या web app के सामान्य Claude Code session जैसा दिखता था, इसलिए run के दौरान उसकी स्थिति को सीधे देखना आसान था
- testing के बाद daily email वास्तव में पहुंचने लगी, और उसके बाद email की सामग्री बदलना भी code बदले बिना routines UI में सिर्फ prompt बदलकर संभव हो गया
- पति-पत्नी जो चीजें देखना चाहते थे वे अलग थीं, इसलिए अलग-अलग daily emails को अलग prompts के साथ सेट किया जा सका
असामान्य लेनदेन और खर्च की निगरानी
- daily email के स्थिर हो जाने के बाद, अलग infrastructure का बोझ उठाए बिना agents चलाने की सुविधा का उपयोग करके और ज़्यादा automation जोड़ना शुरू किया गया
- पहले transaction data के साथ असामान्य लेनदेन की निगरानी बनाई गई, और weekly routine में Amex credit card के 1 साल के लेनदेन लाकर हाल के 7 दिनों पर खास ध्यान देने के लिए सेट किया गया
- अगर हाल के 7 दिनों के लेनदेन पिछले पैटर्न की तुलना में double charge, subscription fee change, या अनजान merchant name या description की तरह अप्रत्याशित हों, तो email भेजने के लिए सेट किया गया
- अगर हाल के 7 दिनों के लेनदेन सामान्य और सुसंगत हों, तो notification न भेजने की सीमा रखी गई
- ऐसे सरल prompts false positive पैदा कर सकते हैं, लेकिन समय के साथ इन्हें refine करने की लागत भी कम लगती है और review cost भी कम दिखाई देती है
- इसके बाद checking account के लिए बड़े और अप्रत्याशित outflow की निगरानी करने वाली routine बनाई गई
- सिर्फ हाल के 1 दिन के लेनदेन की समीक्षा की गई, और पिछले 12 महीनों के पैटर्न से तुलना करके $500 से अधिक के लेनदेन में बड़े outflow या असामान्य outflow खोजे गए
- क्योंकि automation रोज़ चलती थी, इसलिए review scope को सख्ती से सिर्फ हाल के 1 दिन तक सीमित रखा गया
- अगर शर्तों से मेल खाने वाला कोई item हो, तो "Checking account outflow alert" शीर्षक वाला email भेजा जाता था, और नहीं होने पर कोई सूचना नहीं दी जाती थी
- बाद में यही तरीका investment monitoring, subscription analysis और कई spending category की निगरानी तक बढ़ाया गया
- routines में इसे सेट करना बहुत आसान था, इसलिए समय के साथ कई शर्तों को एक साथ जोड़ने या prompts को और परिष्कृत करने की ज़रूरत बढ़ती गई
यह क्यों महत्वपूर्ण है
- routines की सबसे बड़ी ताकत यह है कि इन्हें लगभग बिना मेहनत के आज़माया जा सकता है
- जैसे ही कोई prompt सूझे, automation तुरंत चलाया जा सकता है
- cloud में live data से जुड़ी automation को non-developers भी सीधे संभाल सकते हैं, यह बात खास तौर पर उभरकर आती है
- CPA जीवनसाथी भी Driggsby के real-time data का उपयोग करके अपने लिए automation खुद चला रहे हैं
- इस तरह का उपयोग prompts और connectors के जरिए व्यक्तिगत अनुकूल operational automation को तेज़ी से बनाने में सक्षम बनाता है
1 टिप्पणियां
Hacker News की राय
मैंने हाल ही में इसे खुद इसी तरह सेटअप किया था। https://tiller.com/ से checking/credit card transactions को Google Sheets में sync किया, और GitHub Actions से उस spreadsheet को एक मुफ्त Supabase DB में mirror किया
फिर Supabase MCP या psql के जरिए Claude/Codex को उन transaction records और balances तक English queries से access दिया, और subscription patterns या unusual patterns खोजने की इसकी क्षमता काफ़ी प्रभावशाली लगी। खासकर cash flow forecasting भी अच्छा था, जो online tools अक्सर ठीक से नहीं कर पाते; जैसे मैं पूछ सकता था कि monthly spending patterns और available cash के आधार पर कितनी रकम savings में transfer की जा सकती है
automatic classification के मामले में Claude ने custom DSL को भी काफ़ी अच्छे से handle किया। मैंने payee/category normalization के लिए markdown table ruleset बनवाया, और वे rules भी GitHub Actions में साथ चल रहे हैं
क्या यह Plaid जैसी किसी सेवा के जरिए data pull करता है, या अब भी web banking credentials देने पड़ते हैं, और 2FA को कैसे handle किया जाता है
जिन financial institutions के पास official API नहीं है, क्या वहाँ अब भी screen scraping पर निर्भर रहना पड़ता है? और अगर किसी bug की वजह से अनचाहे clicks, consent, या यहाँ तक कि गलत transfer हो जाए तो क्या होगा? वे इसे read-only कहते हैं, लेकिन personal banking में सचमुच read-only secondary account support करने वाले banks मैंने लगभग नहीं देखे
यह भी जानना चाहता हूँ कि बड़े पैमाने पर financial नुकसान होने पर compensation के लिए कोई insurance या guarantee है या नहीं, और अपना पूरा banking data दो कंपनियों को दिखाने के privacy implications भी चिंता पैदा करते हैं। मैंने class-action lawsuits के बारे में भी सुना है कि data को गलत तरीके से बेचा या share किया गया, लेकिन असल में क्या हुआ था यह नहीं जानता
bank terms में password को third party के साथ share न करने की सहमति वाली clauses भी परेशान करती हैं। web/cloud service को अपनी finances सौंपना मुझे सहज नहीं लगता; local में चलने वाला और bank API से बात करने वाला client software बेहतर लगेगा। यह भी जानना चाहता हूँ कि Canada में ऐसा कुछ है या नहीं
open banking आने की बात तो है, लेकिन यह साफ़ नहीं कि क्या individual द्वारा बनाए गए software से भी access मिलेगा। अगर यह सचमुच भरोसेमंद हो, और download के बाद internal retention को न्यूनतम रखने वाली policies enforce की जाएँ, तो मैं भी bank API इस्तेमाल करना चाहूँगा
Mint के Intuit द्वारा acquisition के बाद से मैं Tiller इस्तेमाल कर रहा हूँ और मेरा setup भी मिलता-जुलता है। बस मैंने local qwen model और OAuth से बनाई गई API key के साथ sheets access जोड़ा है; Claude Routine वाला तरीका शायद कहीं ज़्यादा आसान होता
पूरा setup कैसे किया गया, और खास तौर पर कौन-से prompts इस्तेमाल हुए, यह देखना चाहूँगा
शायद मेरी net worth कम है, लेकिन सच कहूँ तो मुझे समझ नहीं आता कि यह इतना valuable क्यों है
मैं नहीं चाहता कि कोई LLM मुझे रोज़ email भेजे, और अगर मुझे अपने investments को quarterly से ज़्यादा बार देखना पड़ रहा है, तो शायद मुझे और सुरक्षित investments चुनने चाहिए। budgeting tools में थोड़ी दिलचस्पी है, लेकिन मैं चाहूँगा कि वे पूरी तरह deterministic हों
मेरी financial planning आम तौर पर काफ़ी शांत रहती है, इसलिए spending optimization पर अभी से ज़्यादा समय लगाने से बेहतर मुझे ज़्यादा salary वाली नौकरी ढूँढना लगता है
मेरा मानना है कि numbers से जुड़ी चीज़ें मूलतः पूरी तरह deterministic होनी चाहिए
मैंने LLM को SQLite DB दिखाकर कहा कि पिछले 5 साल के transactions में जो दिखता है वह बताए, और उसने जो चीज़ें पकड़ीं या याद दिलाईं वे प्रभावशाली थीं। लेकिन इससे ऐसा कोई व्यावहारिक मूल्य निकला हो जिससे मैं सचमुच कुछ बदलूँ, इस पर मुझे संदेह है
मैं कुछ समय तक इसे monthly review के लिए आज़माऊँगा, लेकिन budget update करते हुए ही मुझे अपनी financial स्थिति का मोटा-मोटा अंदाज़ा रहता है, इसलिए यह कितना मददगार होगा कहना मुश्किल है
मैं उसी से अपने credit card और checking accounts को track करता हूँ, और चाहूँ तो उसमें MCP जोड़कर एक जगह के data का analysis भी कर सकता हूँ
मैं Canada में रहता हूँ और tracking के लिए https://lunchmoney.app/ को Plaid integration के साथ इस्तेमाल करता हूँ
इसमें API है, इसलिए मैंने LLM से एक CLI लिखवाई और अब agent ज़रूरत का data लगभग मनचाहे तरीके से ले सकता है
मैंने एक और काम यह करवाया कि tagging rules को build up करे, और उसे दिन में एक बार cron पर चलाता हूँ। कभी-कभी उससे rules की समीक्षा भी करवाता हूँ ताकि uncategorized transactions के लिए नए rules बनाए जा सकें
मुझे यह pattern काफ़ी अच्छा लगता है जिसमें LLM काम को rule engine या code में memoize कर देता है। एक बार queryable CLI मिल जाए, तो agent से लगभग कुछ भी करवाया जा सकता है
जिन लोगों की दिलचस्पी हो, उनके लिए मैं हमारे infrastructure/security setup का high-level overview साझा कर रहा हूँ
backend और CLI सख़्ती से linted Rust में हैं, और webapp Axum पर चलता है तथा Postgres से sqlx के जरिए जुड़ता है
financial functionality read-only है। transfer/bill-pay/remittance tools नहीं हैं, और AI surface से भी पैसे नहीं हिलाए जा सकते
Plaid से हम सिर्फ़ transactions, investments और liabilities माँगते हैं; auth/transfer/payment initiation नहीं, इसलिए हमें full account numbers या routing numbers नहीं मिलते, सिर्फ़ basic last-4 mask मिलता है
bank usernames और passwords हमारे पास आए बिना Plaid Link में जाते हैं, और हमारे पास सिर्फ़ institution-level access token रहता है
Plaid access tokens को हम अलग DB में रखते हैं और single-custody Cloud Run service के पीछे रखते हैं। store करते समय वे Cloud KMS से encrypt होते हैं, broker KMS encrypt/decrypt endpoints को call करता है, और root key material कभी Google HSM boundary से बाहर नहीं जाता। सिर्फ़ broker service account के पास encrypt/decrypt permission है, और webapp को उस DB को पढ़ने की permission नहीं है
हर encrypt/decrypt call में हम Plaid item ID को AAD के रूप में पास करते हैं ताकि एक item का ciphertext दूसरे item token में बदलकर decrypt न किया जा सके
हर Cloud Run service अपनी अलग cloud identity और DB role के साथ चलती है, और services के बीच internal calls भी short-lived identity tokens से authenticate होते हैं
production DB का कोई public IP नहीं है, और secrets source या container image में नहीं बल्कि managed secret storage में रखे जाते हैं
AI connector OAuth 2.1 + PKCE पर है और user-specific scopes रखता है, जिन्हें UI से revoke किया जा सकता है। हर tool call में tool name, sanitized arguments, calling client, और agent द्वारा दिया गया reason log होता है ताकि यह देखा जा सके कि LLM ने user की ओर से क्या माँगा
AI surface में fetch-URL, shell, या generic I/O tools नहीं हैं; यह सिर्फ़ structured financial data लौटाता है। networking, IAM, और DB grants सब Terraform से manage होते हैं, और infra changes भी सिर्फ़ उसी रास्ते से किए जाते हैं
infra access को 2FA और security keys से नियंत्रित किया जाता है
इससे लगता है कि आप इस साइट के पाठकों को समझते हैं, और सुरक्षा को हर layer पर ध्यान से design करने से पूरे tool पर भरोसा भी बढ़ता है
मैं भी कुछ ऐसा खुद बनाने की सोच रहा था; शुरुआती MVP में manually statement PDFs डाउनलोड करके Claude से plain text accounting के लिए ledger setup करवाने का विचार था, और बाद में Plaid जोड़ने वाला था
खास तौर पर यह जानना चाहता हूँ कि लोग Plaid को कैसे इस्तेमाल करते हैं। शुरू करने के लिए क्या किसी न्यूनतम user count की ज़रूरत होती है, या मैं सिर्फ़ अपने personal/business accounts को clean API से जोड़ने के लिए व्यक्तिगत उपयोग हेतु Plaid account बना सकता हूँ
Routine इस्तेमाल करते समय सावधान रहना चाहिए
एक बहुत कम दिखने वाला छोटा-सा notice है कि routine mode में MCP tools को write permissions सहित हमेशा allow किया जाता है। इसलिए technically agent मनचाहे तरीके से resources बदल भी सकता है
यह मुझे समस्या खोजता हुआ समाधान लगता है। सिर्फ़ https://tiller.com/ ही काफ़ी है, spreadsheet में जो calculations चाहिए वे सब हो जाती हैं, और bonus के तौर पर hallucinations भी नहीं होते
मुझे समझ नहीं आता कि कोई इतना लंबा LLM summary आखिर क्यों पढ़ना चाहेगा। अगर आप बस बीच-बीच में spending को खुद categorize कर लें, तो anomalies जल्दी दिख जाती हैं, और Tiller में यह काम आसान भी है
इस क्षेत्र में बहुत तरह के products आएँगे, और हमारा product उनमें से सिर्फ़ एक approach है। ऐसे प्रयोग ज़्यादा हों, यह मुझे भी अच्छा लगता है
बड़ी बात यह है कि LLM कई data sources को आसानी से absorb और combine कर सकता है
हमारी Era Finance बिल्कुल इसी पर केंद्रित solution बना रही है। यह Era Context नाम का MCP है जो किसी भी compatible agent को personal finance से जोड़ता है, और https://era.app पर देखा जा सकता है
अभी हम read tools पर focus कर रहे हैं, लेकिन money transfer और debt repayment जैसे write tools भी तैयार कर रहे हैं
अगर कोई feature चाहिए तो ऊपर दिए domain के alex पर email करें। जानकारी के लिए, मैं CEO Alex हूँ; HN पर लगभग नया हूँ, लेकिन पहले stripe.com web presence का प्रभारी था और उससे पहले Square/CashApp में था
शायद लड़ाई पहले ही हार चुके हैं, लेकिन फिर भी समझ नहीं आता कि कोई अपना पूरा financial transaction history किसी LLM को क्यों देना चाहेगा
मुझे नहीं लगता कि LLM providers के पास इस data के उपयोग को लेकर financial industry से भी मज़बूत safeguards होंगे। जबकि financial industry खुद ही हमारे data को collect, mine और sell करने वाला काफ़ी कठोर उद्योग है
spending patterns और investments में रुचि रखने वाले इंसान के तौर पर, बहुत basic prompts से भी मैंने ऐसी चीज़ें देखीं जो पहले छूट गई थीं
बेशक इसे सुरक्षित बनाना बहुत कठिन है, और इसी वजह से मैं उस हिस्से पर बहुत लंबे समय से गंभीरता से सोच रहा हूँ
तो फिर ठीक-ठीक समस्या क्या है, यह मुझे समझ नहीं आता
मेरे मुख्य bank, UK के Monzo, में पूरा API और events के लिए trigger webhook है
इसकी वजह से मैं एक WhatsApp bot बना पाया जो unusual transactions पर मुझसे पूछता है कि उसका कारण क्या है, और LLM का उपयोग सिर्फ़ उसकी reasoning के लिए करता है। मैंने एक automation यह भी बनाई है जो हर दिन आधी रात से पहले balance को sweep करके savings account में डाल देती है ताकि daily interest maximize हो सके
मैं day-to-day account में सिर्फ़ थोड़ी रकम रखता हूँ, और अगर दिन में खर्च हो जाए तो savings से फिर भर देता हूँ ताकि वह कम balance बना रहे। बड़े खर्च की ज़रूरत हो तो तब manually transfer करता हूँ
जब मैंने Claude से historical transactions analyze करवाने की कोशिश की, तो यह बार-बार hallucination करता रहा—ऐसे charges बना दिए जो थे ही नहीं, नए items जोड़ दिए, और double counting कर दी
finance में Claude का 95% सही होना काफ़ी नहीं है। हर समय सतर्क रहकर output review करना पड़े, तो मेरे लिए यह लगभग बेकार हो जाता है
मुझे भी लगा है कि Claude खासकर incomplete या constrained datasets पर काफ़ी आसानी से hallucinate कर देता है