Security

A key only you hold

The industry has two names for what this page describes: end-to-end encryption — your details are sealed on your device and can only be opened on your device — and zero-access encryption — what we store, we cannot read. Both apply to everything this page calls “sealed”, and the rest of the page says exactly where that is and where it is not.

Setting up your own encryption key is the first thing you do here, and it isn't optional. It is created in your browser, and we never receive it. What we store is a sealed copy that your passphrase or your recovery code can open, and that nothing we possess can. Your PPS or National Insurance number is locked with it before it leaves your device — so for those, “we can't read it” is a statement about what is possible, not a promise about how we behave.

We made it mandatory rather than a setting, because a promise that only holds for the members who found a toggle isn't one we could put on a page like this.

Behind that, everything else we store is encrypted under a second key held in Amazon's Key Management Service. There is no key material on our servers at all: unsealing requires a request only the running Pegora application is permitted to make, and every one of those requests is recorded.

Where your data physically is

Everything runs in Amazon's Dublin region (eu-west-1): the database, its backups, and the key-management service that holds the second key. Nothing is replicated to a US region, and no part of the running system reaches outside the EU.

AI is the one piece that moves within Europe rather than staying in Dublin. Statement reading and Peggy run on Amazon Bedrock inside this same AWS account, through an EU inference profile that may route between EU regions. Your documents are not sent to an AI company, and there is no API key to an outside model provider anywhere in the system — which is the difference between a policy and an arrangement.

Ireland being an EU state is a real protection — GDPR, and a regulator you can complain to — but it is not a Swiss-style privacy jurisdiction, and we do not claim it is. What the location buys you is that your financial data never leaves the jurisdiction whose tax rules this product implements.

What is encrypted, and what is not

Everything between your browser and Pegora travels over encrypted connections (TLS), and the database itself is encrypted on disk. Your PPS and National Insurance numbers are sealed with the key only you hold, and you only ever see the last few characters of them even on your own screen. Pension portal usernames are encrypted under our Amazon-held key, which we can open — they have to be, because the browser extension that fills them in needs them.

Your investments are sealed with your key. When you add a broker statement, the file is read, priced and worked out inside your browser — the whole tax calculation runs on your own machine — and only then locked and sent to us. Your trades, your holdings and what you owe on them reach us as a block of ciphertext. There is no second copy in a form we can read, and there is no longer any way to upload a statement that produces one. You can see exactly what we hold on the Statements page: it shows you the stored ciphertext itself.

Your pension amounts are sealed with your key too. A pension you record — its value, what goes into it each year, any lump sum taken, what its funds are worth — is locked in your browser before it reaches us, and our own write paths refuse a pension amount that arrives readable. What stays readable is deliberate and named: the provider, the employer it came from, dates, scheme type and fund charges, plus whether a value or contribution is recorded — that is what lets Peggy nudge you about a stale statement without ever knowing a figure. Two honest notes. Amounts recorded before sealing shipped were readable when saved; rather than leave them waiting on a visit that might never come, we deleted them — if yours were among them, you re-enter them once, sealed this time. And when we read a value off an uploaded statement to save you typing it, the document goes to the AI model that reads it — inside our own cloud environment, read once to fill in the form you confirm, stored never.

Your rental income is sealed the same way. An Airbnb statement is read, priced and worked out inside your browser — the file never leaves your device — and your properties, income records and expenses reach us only as ciphertext, like your investments. Records added before this shipped were readable when saved; we deleted them rather than leave a readable copy waiting — if yours were among them, you add them again, sealed this time.

One thing is not yet sealed, and we would rather say so. Your chat with Peggy is stored as you typed it. It is on the same path your investments took.

Pension transfers are different, and permanently so. When you ask us to chase an old pension, we act for you: we write to the provider naming you, your policy and its value, and we read their reply. Correspondence has to be readable to be sent. No arrangement of keys changes that, so we do not claim otherwise. The boundary is drawn where you can see it: starting a transfer shares that one pension's value with us, in readable form, and the form says so before you do it. The pensions you simply track stay sealed.

An audit trail we cannot edit

Every unsealing of a member key is written to a separate, locked store. The records cannot be altered or deleted by us — not by an engineer, not by an administrator, not by anyone holding our accounts — for a year after they are written. The point is not that we promise not to look. It is that looking cannot be done quietly.

The honest limit: we run on Amazon, and whoever controls our Amazon account can change what our systems are permitted to do. What the arrangement above guarantees is that our day-to-day credentials cannot read your data at all, and that changing that requires a deliberate act which is itself permanently recorded. Anyone who tells you their cloud setup makes access impossible is describing marketing, not architecture.

If you lose your key

Anything sealed with it is gone. We cannot reset it, email it to you, or recover what it protected — there is no hidden copy, and a support request cannot conjure one. That is the uncomfortable half of the same fact that makes the promise above true, so we would rather you read it here than discover it later. Keep your recovery code somewhere that isn't the device you sign in on.

What we can still see

Encryption hides contents, not the shape of things. We can see your email address, your plan and payments, when you sign in, the names and sizes of files you upload, and how many records you hold. Your browser also asks us for the exchange rates it needs to convert a statement — that request carries no amounts and is collapsed to one entry per currency-and-day, but it does tell us you traded in, say, dollars on a given date. None of that is hidden, so none of it is claimed to be.

Deleting your account really deletes it

Closing your account removes every record we hold about you, and destroys both of your encryption keys along with them. Because the key is gone, anything encrypted under it can never be read again — including any copy inside a backup, which no ordinary deletion can reach. Backups age out within a month; your key is destroyed immediately.

The AI assistant, plainly

When you talk to Peggy, the AI model that answers runs inside our own AWS account, in the EU, on Amazon's Bedrock service. Your words are processed there and are never sent to Anthropic or to any other AI company, and Amazon does not use them to train models. Our servers refuse to use any other AI route — this is enforced in code, not policy. The honest limit named in the same breath: the model is Anthropic's Claude and the machines are Amazon's, so “our own AI” would be an overclaim — what is ours is the environment it runs in, and the guarantee that your data never leaves it.

What we send alongside your message contains not a single figure of yours — not your salary, not a pension value, not what you owe. Peggy is told what is true and where you can see it, and the exclusion is enforced in code with a test that fails if a figure creeps back in.

Two honest limits. Anything you type to her is sent as you wrote it, and stays in the conversation she is given each turn — we warn you before sending a message that looks like it contains personal numbers, but the choice is yours. And when you upload a document for reading, the whole file goes to the model — still inside our AWS environment, never to an AI company: if your statement has your PPS or National Insurance number printed on it, that page goes too. There is no way to filter a scanned image, so we tell you instead of pretending otherwise.

Every tax figure Pegora shows you is computed by our own rule engine, never by an AI.

No passwords, no card numbers

Sign-in is by emailed link, so there is no password database to steal. Card details are handled entirely by Stripe, our payment provider — they never reach Pegora's servers and we could not show you your own card number if you asked.

Least privilege by construction

The credentials our systems run with can each do exactly one job — the key that sends sign-in emails can send from one address and nothing else; the server can unseal member keys but cannot manage them. Every metered or sensitive action is rate-limited, and the AI features have hard daily spending ceilings per account.

Certifications — honestly

We do not yet hold SOC 2 or ISO 27001 certification, and no outside firm has audited the encryption described above. Those things come with scale, and we would rather tell you exactly what we do than wear a badge we haven't earned. When an independent audit happens, we will publish it in full — including anything it finds.

Found a vulnerability?

Tell us. Security reports are treated as our highest-priority bugs — we will acknowledge quickly, fix quickly, and credit you if you'd like. Contact us at the address on our site.