Private and secure, the way it should be

Your transactions, assets, categories, notes, documents and reports belong to you and to your company. We hold them so the product can do its job, and for no other purpose.

People at Prism do not browse your financial records. Your transactions, balances, documents and reports are looked at when you ask us for help with something and looking at it is the only way to help, and when the law requires it. The support tool that lets an administrator view the product through another user's eyes is restricted to users inside that administrator's own company — there is no facility for our staff to sign in as a customer at another company, and a session using it is labelled as such on every page while it lasts.

Running the service is different, and we would rather spell it out than let the paragraph above imply more than it should. Our platform administrators can see operational information about accounts as a matter of routine, without a support request. That includes, and is not limited to: company and user names and email addresses; which plan an account is on; how many assets, users, transactions and rules it has; the names of the institutions it has connected, when each last synced and any error they returned; and the list of assets it holds, each with its city and state and the market value recorded against it. That last one is a financial figure, and we would rather name it than let the word "operational" quietly cover it. All of it is what is needed to bill accounts, answer support, keep bank connections working and size the service.

The boundary matters more than the list, because a list goes out of date the next time somebody adds a column. It is this: those screens count and summarise accounts, and none of them opens one. No individual transaction, no bank balance, no uploaded document and no report is visible anywhere in the admin tooling — a transaction count, yes; the transactions themselves, never.

Everything else is automated. Bank syncing, categorization and report generation are scheduled jobs; the data goes from your bank to your company's records without a person in the middle. Scenario tools run the same way but on request rather than on a schedule: the exit planner's sale and tax estimates are computed from your company's own records when you ask, are shown to you, and are not written back to your records or sent anywhere else.

Those jobs do email us, though, and that is the honest caveat on the paragraphs above. Several of them copy an operator address at Prism so that a failure is noticed by us rather than by you — or, worse, by your investors. Some of those messages carry real content, not just a status: the investor-report mail attaches the same cash-flow PDF your investors receive, and a scheduled digest of transactions still missing an invoice lists their dates and descriptions. Others are thinner — a sync failed for this asset, a connection needs reconnecting — but they still name the asset.

We are describing the shape rather than listing every job, because that list grows whenever somebody adds an alert and a stale list would be worse than none. The rule is this: automated mail about your account can reach us, and some of it contains your financial detail. It is operational — nothing forwards us your books, and nobody sits reading it as a feed — but it is not nothing, and you should hear it from us rather than work it out.

Prism connects to your financial institutions through Plaid, the same open-banking provider used by a large part of the US financial technology industry. When you link an account you sign in on your bank's own screen or on Plaid's, never on ours. Your bank username and password are never transmitted to us, never handled by us, and never stored by us.

What we receive instead is an access token — a revocable key scoped to the accounts you chose. We ask Plaid only for the transactions product: transaction history and account balances. We do not request payment initiation, transfers, or anything else that could move money, so no part of this system is capable of making a payment from your accounts.

That token is the most sensitive thing we hold, so here is exactly how it is held. Before it is written down it is encrypted with a key of ours, and that key is kept outside the database — so a copy of our database on its own does not yield a working key to anybody's bank data. That sits on top of the encryption the storage layer applies to everything at rest.

What that does not do, and no honest version of this sentence pretends otherwise, is protect against a compromise of the running application — which has to be able to decrypt a token in order to fetch your transactions at all. Encryption at rest defends against a stolen copy. It is not a defence against everything, which is why it is named again in the list at the end of this page rather than left to sound larger than it is.

Most financial data is lost through the front door rather than through the database, so sign-in is where most of the work went.

Passwords

We never store your password. What is stored is a slow one-way hash of it, with a random salt unique to your account, and the comparison at sign-in runs in constant time so that no information leaks from how long it takes. Nobody at Prism can look up, recover or tell you your password — we can only help you set a new one.

A second factor on every password sign-in

A password alone is not enough to reach your data. Signing in with one sends a one-time code to your email, and the code expires on a short timer. You can ask us to remember a browser you trust for 30 days; that record is stored as a hash, it expires on a fixed date and is never extended, and on its own it proves nothing — it only skips the code step after a password has just been verified successfully.

Sign in with Apple is the exception, and deliberately so. On that path we never see a password and we do not send a code: Apple has already authenticated you, on your own device, with whatever protection you have set on your Apple account. We verify the signed token Apple issues and check it was issued for our app. The account is not less protected there — it is protected by Apple's authentication instead of by ours — but it would be wrong to say a code from us is what stands in the way.

Guessing

Repeated failed sign-ins are counted per account and per network address, and lock the attempt out for a cooling-off window. The same limit covers requests to resend a code.

Sessions

Session cookies are marked HttpOnly so no script can read them, Secure so they are never sent over a plain connection, and SameSite=Lax, which stops another site making requests as you in the background. Lax is a reduction, not an end to it: a link you follow from another site is a top-level navigation, and it still carries your session — so an action the app exposes as a plain link, rather than as a form you submit, can still be triggered that way. That is in the list below too. Signing out ends the session, and closing the browser ends most of them. What we do not yet enforce is an absolute lifetime — a session is not force-expired on a fixed clock counted from when you signed in. That is in the list below.

API keys

If you use the API, keys are shown to you once and stored only as a hash — we cannot display an existing key back to you, because we do not have it. Keys can be restricted to a list of network addresses, carry only the permissions you grant them, and can be revoked at any time. The data-query endpoints are rate-limited per key; not every endpoint is yet — that gap is in the list below. A request that fails authentication is told nothing about whether the URL it asked for exists.

Prism is built for companies rather than for individuals, which makes "who can see this" a question with two halves: other customers, and your own colleagues.

Between companies, there is no shared view of anything. Every record in the system — every transaction, asset, category, document, rule and report — carries the identity of the company it belongs to, and every query is filtered by it. No screen, export or API response available to you aggregates across companies — there is no view of the product, at any permission level a customer can hold, that shows another company's anything. The one exception is the operational view described in section one, which is ours rather than a customer's, and which counts accounts without opening them.

Inside your company, you decide. Roles control which parts of the product a person can open and whether they can change anything there, and access can be narrowed further to specific assets — so a property manager can be given one building, and an accountant can be given the reports without the bank connections. Ownership percentages are tracked separately from access, and every change to them is written to an append-only history, so the record of who owned what and when cannot be quietly rewritten.

While you are using it

We keep your data for as long as your account is open, because that is the product: a five-year view of an asset needs five years of transactions. Nothing is deleted for being old.

Taking it with you

Net cash flow reports export to Excel, real-estate schedules to CSV and PDF, and ownership summaries to PDF — all from inside the app, at any time, without asking us. We would rather you never had to request your own data.

What is not there yet is a single button that hands you every raw transaction row. Until it is, ask us and we will produce a full extract of your company's data for you. It is in the list at the end of this page, because a portability promise with a gap in it should name the gap.

Disconnecting a bank

You can disconnect any linked institution at any time. We revoke the access token with Plaid, so the connection ends at the source. The transactions already synced stay in your records — they are your books — until you delete them.

Deleting your account

Email us and we will delete your company's data. We verify that the request comes from someone entitled to make it before we act on it, which is why this is not a button that anyone with a borrowed session could press: for a shared company account, an unverified one-click delete is a way to lose a partnership's records, not a privacy feature.

When we delete an account we remove the financial records that came with it — transactions, assets, categories, connections, rules and reports. We keep only what we are required to keep: billing and tax records of payments actually made, and anything a law or a live legal claim obliges us to preserve. Backups roll off on their own schedule, so a deleted record can persist in an encrypted backup for a short window after it is gone from the live system.

Documents are the one part that is not automatic, and you should know that before you upload one. Receipts and files you attach are stored in a Google Drive that we control, not in the database, and the deletion routine that clears your records does not reach into Drive — it removes the links, not the files. So we delete those by hand as part of processing your request, which is one of the reasons deletion goes through a person rather than a button. If you want the documents gone and nothing else, ask for exactly that and we will do it without touching the rest.

Billing is separate from your data

Ending a subscription is not a deletion. If a subscription lapses, the account becomes read-only and then returns to the free plan. Your data is not deleted for non-payment — nothing is erased at any stage, and all of it is still there if you subscribe again.

While the account is read-only, you can still see everything and still export it. That is deliberate: the read-only guard lets the exports through precisely so that somebody who has stopped paying can still take their data with them.

After the drop to the free plan it is narrower than "not deleted" might suggest, and we would rather be exact than comfortable. Free is a smaller product, and for some things the paid feature is the only way to see the data as well as the only way to export it — uploaded documents and the real-estate schedule are the clearest examples, and they are examples rather than the whole list. Your transactions, assets and categories stay on screen. Anything that lives behind a feature the free plan does not include goes with the feature until you upgrade.

It is still your data, and asking gets it. Write to us and we will produce whatever has gone behind a plan you are no longer on — a lapsed subscription is not going to be the reason you cannot get your own records.

The application runs on Amazon Web Services. Data is stored in MongoDB Atlas, which encrypts it at rest. Everything travelling between your browser and our servers, and between our servers and the databases and APIs behind them, is encrypted in transit with TLS.

Payments are handled by Stripe, a PCI DSS Level 1 service provider. Card numbers are entered on Stripe's own hosted pages and are never sent to, processed by, or stored on our servers — we hold a customer reference and a subscription status, and nothing that could be used to charge a card.

Our infrastructure providers hold the certifications you would expect of them — AWS and MongoDB Atlas are audited against ISO/IEC 27001, SOC 1/2/3 and PCI DSS, and Stripe against PCI DSS Level 1.

Every other service that receives anything of yours is listed below, with what it gets and when. We would rather give you the whole list than a representative sample — a provider list is only worth reading if it is complete, and the section after this one says your data goes to these and to nobody else. The last row is the one exception to "complete", and it says so in the row: which code CDNs a page pulls libraries from is a property of that screen rather than a relationship we hold, so those are named as the ones in use today and not as a closed set.

One entry used to sit at the end of that list and no longer does. Sign-in codes were once deliverable by text message, and on that path the code itself travelled through a third-party automation platform on its way to your phone. That option has been removed rather than documented better: codes now go by email only, through our own mail relay, so there is no longer a delivery route for them that leaves our systems.

We sell software. We do not sell data, and we do not have an advertising business that your financial life could be fed into.

Specifically: your transactions, balances, account holdings, asset values, ownership stakes, tenants, documents and reports are never sold, rented, brokered or shared with data brokers, and are never used to target advertising at you or at anyone else. What you spent, what you own, what you owe and who you bank with play no part in how we market this product. Our marketing consists of telling people Prism exists.

We share data with the service providers listed above, strictly to run the product, and with nobody else — except where a law, a subpoena or a court order compels it, or where you have asked us to.

A security page that only lists strengths is a marketing page. So, plainly:

• We hold no compliance certification of our own — no SOC 2, no ISO 27001. Our providers are certified; we are not.
• We have not commissioned a third-party penetration test, and we do not run a bug-bounty programme.
• Account deletion is a request to us, not a button in the app.
• Sign-in codes are delivered by email only. Hardware keys and authenticator apps — both stronger than a code sent to an inbox — are not supported yet.
• API rate limiting covers the data-query endpoints but not yet all of the newer mobile ones. Those still require a valid key with the right permissions; they just are not throttled.
• We do not run cross-site request forgery protection across the whole app. Sign-in, registration and password changes validate a token; elsewhere the defence is the SameSite cookie above, and because that only covers background requests, a few actions the app exposes as ordinary links could be triggered by a link from another site while you are signed in. Moving those onto submitted forms with a token is on the list.
• Sessions have no enforced absolute lifetime. The cookie protections above apply and signing out works, but we do not yet force a sign-out on a fixed clock from when you signed in.
• There is no one-click export of every raw transaction row. Reports, schedules and ownership summaries export from the app; a full extract is something you have to ask us for.
• Encrypting your bank tokens defends against a stolen copy of the database, and not against a compromise of the running application — which can decrypt them by design, because that is how your transactions get fetched. It is a real protection and a partial one, and we would rather say so than let the word "encrypted" do more work than it has earned.
• When a connection is revoked at Plaid — on disconnect, and on every connection when an account is deleted — a failed call to Plaid is logged rather than retried. It is rare, and it means we do not verify the outcome of every single revocation.
• Some screens still load JavaScript libraries from public CDNs rather than from our own servers, so those providers are contacted by your browser on a signed-in page. Self-hosting them is on the list.
• Notifications have no per-user preferences at all. You can read and dismiss them in the app, but neither you nor we can switch a category off — there is no setting behind it to set, so asking us would not help either. It is on the list.
• Deleting an account does not delete uploaded documents from Google Drive automatically. A person removes them as part of processing the request; nothing in the automated purge reaches Drive.

None of these are secrets, and none of them are reasons to wait — they are the honest shape of a focused product built by a small team, and they are the list we work down. If you have found something we have got wrong, or something that worries you, write to [email protected]. Security reports from customers and researchers are read by a person and taken seriously.

We will update this page when our practices change, and the date at the top will tell you when that last happened.