Treasury & finance
Every morning, the same nine bank logins.
Corporate banking portals have APIs. For treasury clients with a relationship manager and a six-figure implementation. Everyone else gets a browser, a hardware token, and a finance analyst who starts the day signing in.
Forty minutes before anyone knows yesterday’s cash position
-
Sign in to each bank
Corporate ID, user ID, password, then a second factor, an OTP, a hardware token, or an app approval. Some banks bind the session to the device and require re-enrolment when it changes.
-
Download yesterday’s statement
Usually MT940 or CSV, sometimes only a PDF. Choose the account, choose the date range, choose the format, download. Repeat per account.
-
Check payment status
Did the payroll file go through? Is the vendor payment still pending, or has it been returned? The portal is the only place that knows.
-
Move money if needed
Sweep surplus into the operating account, or top up an account that would otherwise go negative.
-
Assemble the cash position
Into a spreadsheet, then into a report, then into a meeting that started five minutes ago.
Statements waiting before the first meeting
- Statement download per account, scheduled before the working day starts.
- Payment status polling: confirm a file was processed, or flag a return, without a human checking.
- Balance reporting across accounts and banks, assembled automatically.
- Read-only by default. Sweeps and transfers are supported, but we recommend starting read-only and widening scope deliberately.
- Immediate revocation: kill a session from the console or API, effective before the next run.
We replay the session, not the password, so there is no credential to steal from our database, and every run starts in a clean browser context.
The parts that need saying out loud
This is the highest-sensitivity use case we support
A banking session is closer to money than anything else on this site. The controls that matter here are the ones you would insist on: per-tenant encryption with the master key in your KMS, a fresh browser context per run, a full audit log, and immediate revocation. On Enterprise, run the whole thing inside your own VPC so we hold nothing at all.
Read-only first, deliberately
We will build the statement-download and status-checking runs before we touch anything that moves money. Payment initiation is supported, but it should be the second phase of a pilot, never the first.
Device binding and hardware tokens
Some banks bind a session to the machine that established it. Capture on that machine, and expect a shorter session lifetime. Where a hardware token is required for every login, the honest answer is that automation reduces the checking rather than removing it.
On bank terms
Several corporate banking agreements restrict automated access. That is your contract. Check it before you pilot this, and ask your relationship manager about sanctioned API access. Some banks grant it on request.
Start read-only, on one bank.
Statements and status only. Nothing moves until you decide it should.