How to automatically download statements from your bank portal

Rindler maps the bank portal once into named actions your agent calls. On Chase, that mapping covers 21 actions across 8 screens, and the two that matter for this question are:

• download_transactions walks the See all transactions flow, captures the CSV server-side, and returns a download link at data.download.url.
• view_statements returns the PDF account statements.

That split is the single most useful thing to know here, and almost every generic answer misses it. If you want machine-readable activity to reconcile against, you want the CSV from download_transactions. If you want the document itself, the thing your accountant or auditor asks for, you want the PDF from view_statements. They are different actions returning different artifacts, and asking for the wrong one is the most common way this task goes sideways.

Every approach to this problem dies in the same place. A scraper gets a login page instead of an account page. A scripted browser works until the bank changes a selector or adds an interstitial. A spreadsheet macro breaks the first time someone is prompted for a code.

Rindler treats the sign-in as part of the mapping rather than as an obstacle in front of it. You sign in once on the real site inside a secure browser. Rindler keeps the resulting session, not your password, and reuses it on later runs. On Chase the SMS identity check is handled inside the login recipe itself, so the flow does not stall waiting for a human the way a hand-rolled script does.

This is also the honest answer to the security question. Your agent never receives your credentials, and the model never sees them. It calls a named action against a session that already exists.

Each step lands on a mapped screen and returns structured output, so your agent is reading records rather than parsing a page.

The accounts overview comes back through view_accounts_overview, a specific card through view_account_detail by account_id, and recent activity through view_transactions. The CSV export resolves on a download_activity screen, and statements and tax documents surface on documents.

The practical shape of a monthly close, then, is: open the accounts overview, drill into each account, call download_transactions for the period, and hand the resulting CSVs to whatever already does your reconciliation. No selectors appear anywhere in that sequence.

This is the fair question, and the honest answer has two halves.

Chase is mapped in depth today, and the transaction download above was proven by driving the real portal end to end rather than inferred from documentation. That is the concrete one.

Every other bank is mapped on request. A mapping is not a generic crawler pointed at a new domain: it is a recorded set of screens and actions, verified against the live site before it ships, and maintained as the site changes. That is why the catalog is not a fixed list and why adding your bank is a scoped piece of work rather than a toggle.

If your honest reaction to that is "so it only works on sites you have already mapped," that is correct, and it is the deliberate trade. The alternative, a tool that will point at any URL immediately, is the same tool that returns a login page for your bank and breaks silently when the layout moves. We would rather tell you which sites are proven than claim all of them and be wrong on the one you need.

Plaid-style aggregators solve a real but different problem. They give you a normalized feed of transactions for institutions they support, on their schedule and their data model, and they sit between you and the bank.

Rindler is not in the middle. It drives the portal you already have access to, using your own session, and returns the artifacts that portal produces, including the actual PDF statement, which an aggregator generally cannot hand you. When the thing you owe someone is a document rather than a feed, that difference is the whole job.

Use an aggregator when you want a normalized multi-bank feed and the institution is supported. Use this when you need the real document, when the portal has no aggregator coverage, or when the workflow is not just reading but also submitting something on the other side.

The four tools your agent calls are the same on a bank portal as anywhere else: start_session, dispatch_action, extract_content, close_session. Your agent discovers what a site can do by calling start_session and reading available_actions, so nothing about the bank is hardcoded on your side.

Sign in to gated sites walks the authentication model, including what is stored and what is not. The Chase mapping lists every mapped action on the portal. If you are weighing this against scraping or a scripted browser, Compare puts the approaches side by side.