FP&A teams pull statements and positions from brokerage or vendor reporting portals so the numbers are in the morning pack. The path is the same each time, and the export has to complete without someone watching.
Claude can interpret a statement. It cannot retrieve one from an authenticated portal on a schedule.
- Claude has no mechanism to hold an authenticated session, survive multi-factor prompts, or persist login state across a scheduled run, so it can reason about financial numbers but can't reliably fetch them from behind a login.
- Financial and investment portals are hardened against automated access, which makes any flakiness in login or navigation especially expensive when the numbers feed a report.
- Computer Use models add screen-level agency but not determinism. They produce unexpected or incorrect behavior 20 to 60 percent of the time, depending on task complexity.
- Compiled agents that reason once at build time and run as code afterward close the reliability, cost, and audit gap that recurring financial extraction needs.
- The durable setup pairs a compiled extraction agent with Claude or a coding agent for judgment on top of the data, not a chat session trying to do both at once.
Where Claude is helpful for scraping financial data behind auth
Claude is genuinely strong once financial data is already in front of it. Give it a statement, a CSV of transactions, or a screenshot of a portfolio dashboard, and it will summarize positions, flag anomalies, reconcile numbers against a prior period, and draft the commentary that goes with them. That's reasoning work, and it's where a language model earns its keep.
The divergence happens before any of that reasoning can start. Scraping financial data behind auth means logging into a bank, brokerage, or billing portal, getting through multi-factor authentication, holding that session across several pages of statements or transaction history, and returning the same structured numbers every time the job runs. None of that is a reasoning task. It's a browser task, and Claude in a chat window has no durable way to do it.
Why scraping financial data behind auth breaks
The first wall is the login itself. Financial portals commonly require multi-factor authentication, device recognition, and short session timeouts, on top of standard passwords. A chat model can type credentials into a form once, in a session you're watching, but it has no vault for storing them and no persistent browser context to reuse the next time the job needs to run unattended.
Even past login, the failure modes stack up. Anti-bot defenses and CAPTCHA challenges on banking and brokerage sites are common precisely because these are high-value targets. Pagination across months of transaction history or multiple linked accounts adds steps a chat session has to re-navigate from scratch each time, since there's no compiled memory of the click path. JavaScript-rendered balances and holdings tables don't always match what a model reading a static page snapshot expects to see.
Then there's the quieter failure: silent partial success. A run that logs in, grabs the first page of transactions, and stops without erroring looks like it worked. For a lead list, that's an annoyance. For a portfolio balance or a reconciliation feed, it's a wrong number in a report nobody double-checks until the numbers don't tie out. Financial data needs to be right every time, and a model re-reasoning through the same login and navigation flow on every run introduces exactly the kind of variability that makes "right every time" hard to promise.
Can't we just use Computer Use?
Computer Use models are a real step forward for screen-level tasks, and the first run against a financial portal often works. The model can see the screen, click the right fields, and get through a login form. That's useful for one-off jobs or exploratory work.
The hidden cost shows up on repetition. Computer Use is still a model reasoning through the interface at each step, which means it's slow and comparatively expensive to run at scale, and it doesn't get more reliable the tenth time you run it. They produce unexpected or incorrect behavior 20 to 60 percent of the time, depending on how complex the task is, which is a wide enough range that you can't build a reconciliation process on top of it without a lot of manual double-checking.
Financial extraction is a repeated task by definition. You need the same account balance pulled the same way every morning, not a system that re-derives its plan for logging in and clicking through statements from scratch each time and occasionally gets it wrong. That's not a knock on Computer Use as a category. It's a mismatch between what agency-per-step buys you and what a recurring, auditable financial feed requires.
What works for scraping financial data behind auth
The fix is to separate judgment from execution. Claude or a coding agent stays in charge of intent, planning, and anything downstream, like flagging a duplicate transaction or writing the summary that goes to finance. The interactive web steps belong to a browser runtime built to handle them reliably every time: logging in, holding the session, paging through statements, and pulling structured numbers.
This is the shape of deterministic AI: reason once, at build time. You describe the extraction once, it gets compiled into code that runs like software, and the model only gets called back in when something on the page genuinely needs judgment, not on every click. For scraping financial data behind auth specifically, an Airtop agent authenticates to any site behind a login, with credentials kept in a secure vault, and can run on a schedule so the same portfolio pull or transaction sync happens every morning without anyone watching it happen.
When a portal changes its layout, a compiled agent doesn't collapse the way a hardcoded script would. Self-healing actions absorb small UI changes using a bit of model intelligence at just that step, instead of re-planning the entire login and navigation flow. That's also where the cost and speed difference shows up: on a comparable multi-step task, a compiled Airtop agent ran in 1 minute 21 seconds for $0.063, against 7 minutes 58 seconds and $6.26 for Claude Code on Opus 4.7, per Airtop's published comparison of the same multi-step task. At the volume a daily financial pull requires across multiple accounts or client portfolios, that gap compounds fast.
Claude and coding agents don't step out of the picture. They move up a layer. Through the Airtop Agents Skill, coding agents can run Airtop agents directly from Claude Code, treating the compiled agent as a tool call rather than trying to drive the browser itself. Claude decides what to check, flags what looks off, and writes the report. The compiled agent does the logging in, paging, and pulling, the same way, every run, with full logs to show for it. This is the broader case for code-first agents vs LLM-first agents: let deterministic code own the repeatable steps, and reserve the model for the parts that genuinely need judgment.
Financial-portal use cases that deterministic agents can solve
Brokerage and banking UIs are built to forget you. Claude can interpret a statement. It cannot own the login, the MFA prompt, or the export button on a cadence.
Download yesterday's activity from a brokerage portal
The useful file is behind a session, a menu, and a date picker. A chat can tell you which columns you want. It cannot keep the session, click Export, and drop the CSV in the same place tomorrow. A compiled agent can, then Claude reads the file.
Pull fund documents that sit behind an investor login
Quarterly letters and fact sheets often live in a portal with no API. Claude is strong at summarizing them. Getting the PDF out of the portal, the same way each quarter, is a browser job with a vaulted password and a stable download step.
Refresh positions from a custodian UI when the API is incomplete
Some custodians expose part of the book in a file you can only reach after login. Re-teaching Computer Use that path every morning is slow and expensive. Compile the navigation once. Let Claude handle exceptions and commentary.
Archive statements before the portal rolls them off
Portals drop older statements on their own schedule. A chat will not remember to grab January before it disappears. A compiled run can collect the file on a calendar, with a video of the click path if someone later asks what was pulled.
Keep Claude for the numbers' meaning, not for reaching them
Scraping financial data behind auth is a login-and-session problem before it's ever a reasoning problem, and chat models were never built to solve the first part reliably. Build the extraction once as a compiled agent, point Claude or a coding agent at the output for analysis and judgment, and the daily pull stops being something you have to babysit.
Try it for free
Spin up your first agent in five minutes and see it authenticate, hold a session, and pull structured numbers from behind a real financial login, the same way every run. Try it for free and stop babysitting the daily pull.
FAQs
Can Claude log into my bank or brokerage account directly?
Not reliably, and not repeatedly. Claude can walk through a login form once in a watched session, but it has no secure vault for credentials and no persistent browser context to reuse the next time the job runs unattended. It also has no built-in way to survive multi-factor prompts or short session timeouts without a human present.
Is it safe to automate scraping behind financial logins?
It's safe when the credentials and session are handled by infrastructure built for it. An agent that authenticates to any site behind a login, with credentials kept in a secure vault keeps sensitive logins out of prompts, chat history, and logs a model might expose. That's a materially different risk profile than typing a password into a chat window.
How is this different from using Computer Use models for financial data?
Computer Use models add screen-level agency, but they still reason through every click at runtime, and they produce unexpected or incorrect behavior 20 to 60 percent of the time depending on complexity. A compiled agent reasons once at build time and then runs the same way every time, which matters far more for numbers that feed a reconciliation or a report.
Can I run this on a schedule for daily reporting?
Yes. A compiled agent can run on a schedule or trigger, pull the same statements or balances each time, and produce full logs for audit purposes, which is closer to a scheduled agent with full run logs than to a one-off chat session you have to babysit and rerun manually.
What happens when a bank or brokerage portal changes its layout?
A hardcoded script breaks immediately when a page changes. A compiled agent uses self-healing actions, calling in a small amount of model intelligence only at the step that changed, instead of re-planning the whole login and navigation flow from scratch. That keeps a daily financial pull running through minor UI updates without manual fixes.
Should I use an API instead of scraping the portal?
If the financial provider exposes a real API with the data you need, use it. Browser automation is for the more common case where the numbers only exist inside an authenticated web UI. The guidance on when to use browser automation instead of an API covers how to decide, and many real workflows end up hybrid, calling an API where one exists and falling back to the browser where it doesn't.
Can I connect this to Claude Code or another coding agent I already use?
Yes. You can connect Claude Code to Airtop and call compiled extraction agents as tools from inside your existing coding-agent workflow, so Claude keeps handling judgment and orchestration while the browser work runs separately and deterministically.
Who builds and maintains the extraction agent?
You can build it yourself in Agent Builder, or describe the extraction to Mark to get a working agent set up faster. Either way, the extraction logic is compiled once and reused, rather than re-prompted every run.
