You are about to connect your bank. Here is exactly what happens.
No vague reassurance about bank-grade encryption. What we can see, what we cannot do, where it lives, and what we can actually evidence.
Bank connections use the GoCardless Bank Account Data API, which is an account information service only. It grants access to your account list, balances and transaction history, and carries no payment initiation capability at all. There is no instruction we could send that would move a penny, because the connection has no mechanism for one.
You authenticate with your bank directly, through their own screens. Credentials never touch our systems, and we could not retrieve them if we wanted to.
From the app or from your bank. Access ends immediately, and you choose whether the history already imported stays or goes.
We do not sell it, we do not share it with advertisers, and we do not train anything on your books. Revenue comes from subscriptions, which is the only arrangement where our interests and yours point the same way.
Isolation enforced underneath the app, not by it.
Most security pages describe intentions. These are mechanisms, and each one is checked by the build.
Every table is governed by PostgreSQL row-level security, so one account cannot read another's rows even if application code were to ask for them. Isolation is enforced underneath the app rather than by it.
Anything that needs elevated permission runs in an audited edge function with a registry of what may use service-role access, rather than in code shipped to your browser.
Bank tokens, HMRC credentials, names, balances, amounts, transaction descriptions and National Insurance numbers are on an explicit never-log list, enforced by a shared logging helper with regression tests.
Secret scanning, a sensitive-logging guard, row-level-security proofs, schema-usage proofs and a service-role registry check all run in CI. A change that breaks one of them does not ship.
An explicit list, enforced by tests.
Logging is where financial data usually leaks, because nobody means to do it. These values are on a never-log list with a shared helper and regression tests behind it.
- Bank provider tokens
- HMRC credentials and tokens
- Service-role and payment provider secrets
- Names, emails and addresses
- Account numbers and balances
- Transaction descriptions and amounts
- Tax values and National Insurance numbers
The specifics
Everything here should be checkable. If a row cannot be evidenced, it does not belong on the page.
Who else touches your data
Every company we rely on to run the product, what each one is for, and where it processes. We give notice before this list changes.
Database, sign-in, file storage and server functions
Hosting, content delivery and request logs
Read-only open banking connections to your bank
Subscription billing and card payments
Sign-in links, invitations and notification email
Checks a new password against known breaches. Your browser sends the first five characters of a hash, never the password itself
Reads your public IP address, which HMRC requires inside the fraud prevention headers on any tax submission
These receive data because you instructed us to send it, not because we hired them to handle it on our behalf.
Tax submissions, obligations and the fraud prevention data HMRC requires with them
Company lookup, and statutory filings where you choose to make them
Found something? Tell us.
We will acknowledge it, keep you updated, and credit you if you want it. We will not threaten you with lawyers for reporting a bug in good faith.
Report it hereLarger clients and their accountants tend to want documents rather than a web page.
- Security overview, PDF
- Sub-processor list
- DPA and standard contractual clauses