Claude Code rutinleri finansımı gözetebilir mi?
(driggsby.com)- Finansal hesap verileri ve MCP konektörleri bağlandığında, bakiye, işlem geçmişi, yatırım ve kredi bilgilerine dayanarak tekrarlayan finansal kontroller yalnızca istemlerle otomatikleştirilebiliyor
- Mevcut Codex CLI cron-job yaklaşımı; web oturumu açma, tarayıcı render sorunları, 2FA ve passkey kısıtları nedeniyle sık sık bozuluyor, bu yüzden hesap bazlı kontrolleri istikrarlı biçimde sürdürmek zor oluyordu
- Yeniden kurulan günlük e-posta otomasyonu, sabah zamanlaması, custom connector ve
email_me()aracını birleştirerek tüm hesapları ve net serveti derleyip gönderecek şekilde kuruldu; içerik de yalnızca istem ayarlanarak değiştirilebiliyor - İşlem izleme otomasyonu, olağandışı işlemleri ve büyük çıkışları son dönem örüntüleriyle karşılaştırarak tespit ediyor ve yalnızca koşullar sağlandığında e-posta göndererek gereksiz bildirimleri azaltıyor
- Bu yaklaşım, kişiselleştirilmiş operasyon otomasyonunu çok düşük maliyetle hızla denemeyi ve ölçeklemeyi mümkün kılıyor; gerçek zamanlı verilere bağlı finansal kontrolleri geliştirici olmayanların da doğrudan kullanabilmesini sağlıyor
Otomasyonun nasıl kurulduğu
- Driggsby, Plaid ile finansal hesaplara bağlandıktan sonra MCP üzerinden bakiye, işlem geçmişi, yatırım bilgisi ve kredi bilgisi gibi araçları sunuyor
- İlk başta odak, Claude içinde gerektiğinde soru sormaya dayalı etkileşimli kullanımdı; ancak net servet kontrolü, bakiye inceleme ve işlem izleme gibi tekrar eden kalıplar ortaya çıktı
- Claude Code routines, bu tekrar eden işleri yalnızca istemlerle otomatikleştirmeyi kolaylaştırıyor
- Ayrı bir agent loop kodu yazmadan veya dağıtım ortamı hazırlamadan, yalnızca istemleri ve MCP konektörlerini bağlayarak çalıştırmak mümkün
- Veri ve araçlar MCP konektörleriyle temiz biçimde bağlanabiliyorsa otomasyon kurulabiliyor
Eski yaklaşımın sınırları ve geçiş
- Daha önce, etkileşimsiz bir Codex CLI cron-job ile banka, kredi kartı, aracı kurum ve emeklilik hesaplarında oturum açıp bakiyelerle son işlemleri çekiyor ve günlük finans özeti e-postası gönderilecek şekilde bir düzen kurulmuştu
- Her siteye giriş yapmak ve bilgileri çıkarmak için Chrome DevTools MCP kullanılıyordu
- Eşlere günlük finans özeti e-postası gönderen basit bir işti, ancak gerçekte sık sık bozuluyordu
- Ertesi gün hemen başarısız olması tekrar tekrar yaşanıyordu; tarayıcı render sorunları veya beklenmedik 2FA istekleri nedeniyle hesap düzeyinde süreç durabiliyordu
- GPT bazen e-posta biçimini tamamen değiştiriyor ya da çalışırken karışıp yalnızca tek bir hesabın bilgisini getiriyordu
- Yeni eklenmesi gereken bazı hesaplar yalnızca passkey ile oturum açmaya izin veriyordu
- Bu tekrar eden aksaklıklar nedeniyle beklenen e-posta gelmediğinde her seferinde elle müdahale etmek gerekiyordu; bu süreci daha az stresli hale getirmek için Driggsby geliştirildi
Günlük e-posta otomasyonu
- İlk yeniden kurulan şey günlük e-posta oldu; amaç her sabah tüm hesapları ve net serveti temiz bir biçimde özetleyen bir ileti almaktı
- Bu bilgiler aslında Google Drive'da bir yerlerde duran eski bir hesap tablosundaydı
- Güncellemesi yalnızca yaklaşık 15 dakika sürüyordu, ancak bu küçük sürtünme yüzünden sık güncellenmiyordu ve en fazla yaklaşık altı ayda bir yenileniyordu
- routines içinde, istem girişi, sabah zamanlaması ve Driggsby custom connector bağlantısıyla ilk kurulum çok kolay tamamlandı
- Ancak başta e-posta göndermenin bir yolu yoktu; Gmail connector eklendiğinde yalnızca iyi düzenlenmiş bir taslak üretildi
- Gmail connector gerçek gönderim yapamıyor, yalnızca draft oluşturabiliyordu
- Bunu çözmek için Driggsby'ye
email_me()MCP aracı eklendi ve bu yaklaşım oldukça kullanışlı çalıştı- Güvenlik açısından kabul edilebilir düzeyi korumak için gönderim hedefi yalnızca hesap sahibinin doğrulanmış e-postasıyla sınırlandı; bağlantılar ve görseller engellendi
- Gövde Markdown olarak zorunlu kılındı ve Markdown render eden e-postalara CSS eklenerek her çalıştırmada ortaya çıkan biçim tutarsızlıkları azaltıldı
- Birkaç küçük hata, routines'in inspectability özelliği sayesinde nispeten kolay düzeltildi
- Arayüz, Claude Desktop veya web uygulamasındaki tipik Claude Code oturumlarına benzediğinden çalışma durumunu doğrudan incelemek kolaydı
- Testlerden sonra günlük e-posta gerçekten ulaşmaya başladı; sonrasında da e-posta içeriğini değiştirmek için kodu değiştirmeden, routines arayüzünde yalnızca istemi ayarlamak yeterli oldu
- Eşlerin baktığı kalemler farklı olduğundan, her biri için farklı günlük e-postalar ayrı istemlerle yapılandırılabildi
Olağandışı işlemler ve harcama izleme
- Günlük e-posta oturduktan sonra, ayrı bir altyapı yükü olmadan agent çalıştırabilme avantajıyla daha fazla otomasyon eklenmeye başlandı
- Önce işlem verileriyle olağandışı işlem izleme kuruldu; haftalık çalışan routine, Amex kredi kartının bir yıllık işlemlerini çekiyor ama özellikle son 7 güne odaklanacak şekilde ayarlanıyordu
- Son 7 gündeki işlemler, geçmiş örüntülerle karşılaştırıldığında mükerrer tahsilat, abonelik ücretinde değişiklik ya da tanımadık satıcı adı veya açıklaması gibi beklenmedik durumlar içeriyorsa e-posta gönderilecek şekilde ayarlandı
- Son 7 günün işlemleri normalse ve tutarlıysa bildirim gönderilmemesi sınırlandı
- Bu kadar basit bir istem false positive üretebilir, ancak zamanla iyileştirme maliyetinin ve inceleme maliyetinin düşük kalacağı düşünülüyor
- Ardından vadesiz hesap için beklenmedik büyük çıkışları izleyen bir routine oluşturuldu
- Yalnızca son bir günün işlemleri inceleniyor ve son 12 ayın örüntüleriyle karşılaştırılarak 500 dolar üzerindeki işlemler içinde büyük veya sıra dışı çıkışlar aranıyordu
- Otomasyon her gün çalıştığı için inceleme kapsamı özellikle son bir günle sıkı biçimde sınırlandı
- Koşullara uyan kalem varsa başlığı "Checking account outflow alert" olan bir e-posta gönderiliyor, yoksa bildirim yapılmıyordu
- Sonrasında bu yaklaşım yatırım izleme, abonelik analizi ve çeşitli harcama kategorilerinin takibine kadar genişletildi
- routines ile kurulum çok kolay olduğu için zamanla birden fazla koşulu bir araya getirme veya istemleri daha ayrıntılı biçimde rafine etme ihtiyacı büyüyor
Neden önemli
- routines'in temel gücü, neredeyse hiç çaba harcamadan denenebilmesi
- Aklına bir istem geldiğinde otomasyonu hemen çalıştırabiliyorsun
- Bulutta, canlı veriye bağlı otomasyonların geliştirici olmayanlar tarafından da doğrudan kullanılabilmesi özellikle dikkat çekiyor
- CPA olan eşi de Driggsby'nin gerçek zamanlı verilerini çekip kendi otomasyonlarını doğrudan çalıştırıyor
- Bu kullanım biçimi, yalnızca istemler ve konektörlerle kişiselleştirilmiş operasyon otomasyonunu hızla kurmayı mümkün kılıyor
1 yorum
Hacker News görüşleri
Kısa süre önce bunu bizzat böyle kurdum. https://tiller.com/ ile vadesiz/kredi kartı işlemlerini Google Sheets’e senkronize ediyor, ardından GitHub Actions ile bu hesap tablosunu ücretsiz bir Supabase veritabanına yansıtıyorum
Supabase MCP veya psql üzerinden Claude/Codex’in işlem geçmişine ve bakiyelere İngilizce sorgularla erişmesini sağladım; abonelik örüntülerini ya da sıra dışı kalıpları bulma becerisi epey etkileyiciydi. Özellikle çevrimiçi araçların pek iyi yapamadığı nakit akışı tahmini de fena değildi; örneğin aylık harcama düzeni ve kullanılabilir nakde göre ne kadarını birikime aktarabileceğimi sorabiliyordum
Otomatik sınıflandırma tarafında ise Claude, özel bir DSL ile oldukça iyi çalıştı. Alıcı/kategori normalizasyonu için markdown tablo tabanlı bir kural seti oluşturttum; bu kurallar da GitHub Actions içinde birlikte çalışıyor
Plaid benzeri bir şey üzerinden mi çekiyor, yoksa hâlâ internet bankacılığı kimlik bilgilerini vermek mi gerekiyor, 2FA nasıl ele alınıyor bilmek isterim
Resmî API’si olmayan finans kurumlarında hâlâ screen scraping’e mi dayanıyorlar, ayrıca bir hata yüzünden istenmeyen tıklamalar, onaylar, hatta yanlış para transferleri gibi şeyler olursa ne olur diye de endişeliyim. Salt okunur deniyor ama kişisel bankacılıkta gerçekten salt okunur yardımcı hesap destekleyen banka neredeyse hiç görmedim
Büyük çaplı mali zarar durumunda tazmin alabilmek için sigorta ya da güvence olup olmadığını da merak ediyorum; ayrıca tüm banka verilerini iki ayrı şirkete göstermenİN gizlilik sonuçları da kaygı verici. Verilerin uygunsuz biçimde satıldığı/paylaşıldığı toplu davalarla ilgili bir şeyler duydum ama gerçekte ne yaşandığını bilmiyorum
Banka sözleşmelerindeki “şifreyi üçüncü taraflarla paylaşmayacağım” maddesi de takılıyor. Finansımı web/bulut hizmetlerine emanet etmek bana pek iyi gelmiyor; yerelde çalışan ve banka API’leriyle iletişim kuran istemci yazılımı daha iyi olurdu. Kanada’da böyle bir şey var mı onu da merak ediyorum
Açık bankacılığın geleceği söyleniyor ama bireyin kendi yazdığı yazılımla erişip erişemeyeceği belirsiz. Gerçekten güvenilir olur ve indirildikten sonra içeride tutulan veriyi en aza indiren politikalar zorunlu kılınırsa ben de banka API’lerini kullanmak isterim
Mint, Intuit tarafından satın alındığından beri Tiller kullanıyorum ve benzer bir kurulumum var. Yalnız ben yerel bir qwen modeli ve OAuth ile oluşturulmuş API anahtarı üzerinden Sheets erişimini bağladım; Claude Routine yaklaşımı muhtemelen çok daha kolay olurdu
Genel kurulum biçimini, özellikle de hangi prompt’ları kullandığını görmek isterim
Net servetim düşük olduğu için olabilir ama dürüst olmak gerekirse bunun neden değerli olduğunu pek anlamıyorum
LLM’in bana her gün e-posta göndermesini istemem; yatırım durumuma çeyrekte birden daha sık bakmam gerekiyorsa muhtemelen daha güvenli yatırımlara yönelmem gerekir. Bütçe araçlarına biraz ilgim var ama onların tamamen deterministik olmasını isterim
Finansal planlamam genel olarak sakin; bu yüzden şu ankinden daha fazla harcama optimizasyonuna zaman ayırmaktansa maaşı daha yüksek bir iş aramanın daha iyi olduğunu düşünüyorum
Sayılarla ilgili her şeyin zaten tamamen deterministik olması gerektiğini düşünüyorum
LLM’e SQLite veritabanımı gösterip son 5 yıldaki işlemlerde ne gördüğünü anlatmasını istedim; yakaladıkları ve bana hatırlattıkları etkileyiciydi. Ama bunun gerçekten benim bir şeyi değiştirmeme yol açan somut bir değeri oldu mu, emin değilim
Bir süre aylık olarak gözden geçirmesini deneyeceğim ama sadece bütçeyi güncellerken bile finansal durumumu zaten büyük ölçüde biliyor oluyorum; ne kadar yardımcı olacağı belirsiz
Ben bununla kredi kartı ve vadesiz hesaplarımı takip ediyorum; istersen oraya MCP bağlayıp tüm veriyi tek yerden analiz etmek de mümkün
Kanada’da yaşıyorum ve takip için https://lunchmoney.app/ hizmetini Plaid entegrasyonu ile kullanıyorum
Bir API’si var; bu yüzden bir LLM’e bir CLI yazdırdım ve bu sayede ajan ihtiyaç duyduğu veriyi neredeyse istediği gibi çekebiliyor
Ona yaptırdığım başka bir şey de etiketleme kuralları biriktirmekti; bunu günde bir kez cron ile çalıştırıyorum. Bazen kuralları gözden geçirmesini sağlayıp sınıflandırılmamış işlemler için yeni kurallar da ürettiriyorum
LLM’in işi kural motoruna ya da koda dönüştürerek kalıcılaştırmasını sağlayan bu modelin oldukça iyi olduğunu düşünüyorum. Sorgulanabilir bir CLI olduktan sonra ajana neredeyse her şeyi yaptırabilirsiniz
İlgilenenler için bizim altyapı/güvenlik düzenimizin genel çerçevesini paylaşayım
Backend ve CLI sıkı linting uygulanan Rust, web uygulaması Axum üzerinde çalışıyor ve Postgres’e sqlx ile bağlanıyor
Finansal özellikler salt okunur. Para transferi, fatura ödeme ya da havale araçları yok; AI yüzeyinde de parayı hareket ettirmek mümkün değil
Plaid’den yalnızca işlemler, yatırımlar ve borçlar isteniyor; auth/transfer/payment initiation istenmediği için tam hesap numarası veya routing number almıyoruz, yalnızca temel son-4 maske geliyor
Banka kullanıcı adı ve şifresi bize uğramadan doğrudan Plaid Link’e gidiyor; biz sadece kurum bazlı access token tutuyoruz
Plaid access token’ları ayrı bir veritabanında tutup tek bir custody Cloud Run hizmetinin arkasına koyuyoruz. Depolama sırasında Cloud KMS ile şifreleniyor; broker KMS encrypt/decrypt uç noktalarını çağırıyor ve kök anahtar materyali Google HSM sınırlarının dışına çıkmıyor. Yalnızca broker hizmet hesabının şifreleme/çözme yetkisi var; web uygulamasının o veritabanını okuma yetkisi yok
Tüm şifreleme/çözme çağrılarında Plaid item ID’yi AAD olarak gönderiyoruz; böylece bir öğenin şifreli verisi başka bir öğenin token’ına çevrilip çözülemiyor
Her Cloud Run hizmeti kendi bulut kimliği ve DB rolüyle çalışıyor; hizmetler arası iç çağrılar da kısa ömürlü identity token’larla doğrulanıyor
Üretim veritabanının public IP’si yok; sırlar kaynak kodunda ya da container imajında değil, yönetilen secret storage içinde tutuluyor
AI connector OAuth 2.1 + PKCE kullanıyor ve kullanıcı bazlı scope’lara sahip; UI üzerinden revoke edilebiliyor. Tüm tool call’larda araç adı, temizlenmiş argümanlar, çağıran istemci ve ajanın sunduğu gerekçe kaydediliyor; böylece LLM’in kullanıcı adına ne talep ettiğini görebiliyorsunuz
AI yüzeyinde fetch-URL, shell veya genel amaçlı I/O araçları yok; yalnızca yapılandırılmış finansal veri döndürülüyor. Ağ yapılandırması, IAM ve DB yetkileri tamamen Terraform ile yönetiliyor; altyapı değişiklikleri de yalnızca bu yol üzerinden yapılıyor
Altyapı erişimi 2FA ve güvenlik anahtarlarıyla kontrol ediliyor
Bu sitenin okur kitlesini anladığın hissini veriyor; güvenliği her katmanda özenle tasarlamış olmanız da araca olan güveni artırıyor
Ben de benzer bir şeyi kendim kurmaya çalışmıştım; ilk MVP, ekstre PDF’lerini elle indirip Claude ile düz metin muhasebesi için ledger kurmaktan ibaretti ve sonra Plaid eklemeyi düşünüyordum
Özellikle insanların Plaid’i nasıl kullandığını merak ediyorum. Başlamak için belli bir kullanıcı sayısı gerekiyor mu, yoksa sadece kendi kişisel/iş hesaplarımı temiz bir API’ye bağlamak için kişisel kullanım amaçlı Plaid hesabı açabilir miyim?
Routine kullanırken dikkatli olmak gerekir
Neredeyse fark edilmeyen küçük bir not var: routine modunda MCP araçları yazma izni de dâhil olmak üzere her zaman izinli oluyor. Bu yüzden ajan teknik olarak kaynakları keyfine göre değiştirebilir
Bu bana çözüm arayan bir sorun gibi geliyor. https://tiller.com/ tek başına zaten yeterince iyi; istediğiniz tüm hesaplamaları e-tabloda yapabilirsiniz ve bonus olarak halüsinasyon da yok
Okunması gereken uzun LLM özetlerini neden isteyesiniz onu da pek anlamıyorum. Harcamaları ara sıra elle sınıflandırmak bile aykırı durumları hızla görünür kılıyor; Tiller ile bunu yapmak da kolay
Bu alanda gerçekten çok farklı ürünler çıkacak ve bizim ürünümüz de bunlardan sadece bir yaklaşım. Bu tür denemelerin artmasını ben de olumlu görüyorum
Asıl önemli olan LLM’lerin birden fazla veri kaynağını kolayca alıp birleştirebilmesi
Biz Era Finance olarak tam da buna yönelik bir çözüm geliştiriyoruz. Uyumlu herhangi bir ajanı kişisel finansla bağlayan bir MCP olan Era Context ve https://era.app adresinde görülebilir
Şu an okuma araçlarına odaklanıyoruz ama para transferi ya da borç ödeme gibi yazma araçları da yolda
İstenen bir özellik varsa yukarıdaki alan adındaki alex’e e-posta atılmasını isterim. Bu arada ben CEO Alex; HN’de neredeyse yeniyim ama daha önce stripe.com’un web varlığından sorumluydum, ondan önce de Square/CashApp’teydim
Belki savaş çoktan kaybedildi ama neden tüm finansal işlem geçmişinizi bir LLM’e vermek isteyesiniz, anlamıyorum
LLM sağlayıcılarının bu tür verilerin kullanımı konusunda finans sektöründen daha güçlü korumalara sahip olduğunu da sanmıyorum. Finans sektörü zaten verilerimizi toplayan, çıkaran ve satan oldukça acımasız bir endüstri
Harcama kalıpları veya yatırımlarla ilgilenen biri olarak, çok temel prompt’larla bile daha önce kaçırdığım şeyleri fark ettiğim oldu
Elbette bunu güvenli hale getirmek çok zor ve bu yüzden o kısım üzerine çok uzun süre düşündüm
O zaman tam olarak sorun ne, pek anlayamadım
Birleşik Krallık’taki ana bankam Monzo, tam API ve olaylar için trigger webhook sağlıyor
Bu sayede anormal işlem olduğunda nedenini açıklamasını isteyen bir WhatsApp botu yapabildim; LLM’i sadece bu muhakeme kısmında kullanıyorum. Ayrıca günlük faizi maksimize etmek için her gece yarısından önce bakiyeyi birikim hesabına süpüren bir otomasyon da kurdum
Günlük hesabımda yalnızca küçük bir miktar tutuyorum; gün içinde para harcayınca bu düşük bakiyeyi korumak için birikimden tekrar dolduruyorum. Daha büyük bir harcama gerekirse o zaman elle aktarıyorum
Claude ile geçmiş işlemleri analiz etmeye çalıştığımda, var olmayan ücretler uydurma, yeni kalemler ekleme ve çift sayma gibi halüsinasyonlar sürekli oldu
Finans söz konusu olduğunda Claude’un %95 doğru olması yeterli değil. Sonuçları sürekli tetikte olup gözden geçirmek gerektiği için benim durumumda fiilen değersiz hale geliyor
Ben de Claude’un özellikle eksik ya da sınırlı veri kümelerinde halüsinasyona oldukça yatkın olduğunu düşünüyorum