On this page
The short version
- Month Audit is a small pilot. You forward receipts to a single shared address; we email weekly and monthly summaries back.
- Forwarded receipts are read by Claude (Anthropic's model) running inside AWS Bedrock, parsed into structured records, and used to generate your summaries. Any PDF we can open also goes to that model to be told apart from a statement, which happens even before you confirm. A password‑protected one, one larger than about 20 MB, and any after the tenth PDF we actually send from one message never reach it. Most of this stays inside Amazon Web Services — see who we share it with for the exceptions.
- Raw forwarded emails are kept 30 days, then truncated to parsed records — and statement PDFs you forward are kept for the same 30 days, counted from when we store them. What we extract from a statement, once we start doing that, stays until you delete your account — the PDF goes at 30 days, what we extract from it does not. Parsed records are kept until you ask us to delete them. Summaries are kept 12 months rolling.
- We don't sell your data, share it with advertisers, or use it to train any AI model. Bedrock‑with‑Anthropic is configured so your data is not used for model training.
- We don't ask for or require bank credentials, credit card numbers, or government IDs, and nothing in the service needs them — but we also don't scan what you forward — receipts or statements — to strip one out if it happens to appear — see What data we collect.
- So we can debug bad results, we log what we send to the model and what it sends back. That log includes what we send and what comes back — the text of the forwarded email, and whatever AWS keeps of any photographs or PDFs that went with it. A statement PDF is sent to the model the same way, so whatever AWS keeps of that exchange is kept the same way too. It's kept 30 days. If you delete your account, these logs age out on their own 30‑day clock rather than vanishing immediately. One exception: if you email us again after deleting your account, that message is still classified before we recognise the account is gone, which creates one more log entry either way. A non‑receipt message is then dropped without reply; one we recognise as a receipt from its own subject and text starts a fresh subscription, with a confirmation email you must reply
confirmto before anything is parsed. One sent as just an attachment with little else written may not be recognised. - You can pause, resume, or delete everything by replying in plain English to any email from us — no special keywords. For deletion, we'll send a one‑time 6‑digit code to confirm; this defends against someone spoofing your email address.
- The summary emails we send include a small open‑tracking pixel (via AWS SES) so we can see whether emails are being opened. You can block it by disabling remote image loading in your email client — see Cookies and Tracking.
- This is a pilot, currently operated by an individual rather than a company. See “Who is the data controller?” below.
Who is the data controller?
Month Audit is currently operated by an individual based in Dubai, United Arab Emirates, as a sole proprietorship pilot project. The operator's full legal name is provided in writing on request to verified data‑rights requests at hello@monthaudit.com, and to any data‑protection authority on request.
If incorporation occurs before or during the pilot, this notice will be updated to name the legal entity as controller, and active users will be notified by email.
Contact: hello@monthaudit.com
What data we collect
When you first forward a receipt to review@receipts.monthaudit.com:
- The
From:address on the message. - The full content of the forwarded email — sender, subject, date, body, and any attachments (PDFs).
- A user record in
pending‑confirmationstate. The parked message is stored but not parsed until you confirm.
When you reply to our confirmation email or any later email from us:
- The full text of your reply.
- The intent the system inferred from it:
confirm,pause,resume,delete_intent,delete_token, orengagement. Replies the system can't confidently classify are forwarded to the operator for a manual response. - For deletion specifically: a one‑time 6‑digit token issued at the deletion request, valid for 24 hours, single‑use, never reused.
When you forward more receipts (after confirmation):
- The full email content, parsed into structured records — merchant, date, amount, currency, line items, fees, and an inferred category from a fixed list.
When you forward a bank or card statement:
- The statement PDF itself. Any PDF we can open — receipts included — also goes to the model in full, which reads it far enough to tell a statement from a receipt: which bank or card it is, whether it shows an account number, whether it covers a period, whether it lists transactions. That happens even before you confirm, and nothing we read that way is kept beyond the windows below. Some PDFs never reach the model at all: one that is password‑protected, one larger than about 20 MB, and any after the tenth PDF we actually send from one message. A PDF we do send but then decline to go further with — because it is over our per‑document size or page limit — has still been read that far.
- Once statement reconciliation is running, which it is not yet: what we extract from a statement — which bank or card issuer it is with, what kind of account it is, its currency and country, the last few digits of the account number, the period it covers, its opening and closing balances and totals, and each transaction line.
- Anything you would tell us in reply if we asked you about a line we could not place — your answer in your own words, and the rule we derive from it. We do not ask yet.
Derived from the emails you send us (we don't ask you for these, and you don't type them in):
-
Your UTC offset. We read it from the
Date:header stamped on the messages you send us — not only receipt forwards: any reply we act on rather than ignore counts too, such as aconfirm, or aresumeafter a pause — and store it as a number of minutes ahead of or behind UTC, for example+04:00. We do not choose which offset that header states; whatever stamped the message does, which may be your own mail app or a forwarding rule or webmail provider acting on your behalf. Until we have read a usable header at least once, we treat you as being on UTC; after that, a message that doesn't carry a readable one simply leaves the last value we did read in place.We use it in a few places, all about calendars. The most visible is deciding when your day, week and month begin and end — that covers the weekly and monthly summaries, and also the day‑level figures in the reply we send back when you forward a receipt: its running total, its category breakdown and its needs/wants split. The weekly summary also prints the offset in its own heading, so you can see which calendar it was built on. It matters right after one of those boundaries: if your offset is
+04:00, a purchase you made at 02:00 on a Sunday happened at 22:00 the previous Saturday in UTC — so counting it in UTC would file it under the week that had just finished for you instead of the one that had just started. West of UTC the mirror case applies, late on a Saturday. Another is less obvious and we would rather spell it out: when a receipt prints a purchase time but no time zone of its own, we assume that time was written in your offset, and that is what fixes the exact moment we store for the purchase. For receipts that carry no order number, we compare those stored moments as part of deciding whether two forwards are the same purchase — so your offset can also affect whether two forwards of one purchase collapse into a single record or are kept as two.It is a fixed offset, not a place:
+04:00is shared by Dubai, Baku and Samara, and we store nothing that tells them apart — no city, no country, no daylight‑saving history. It is still a coarse indication of roughly how far east or west of UTC you are, so we would rather list it here than leave it unsaid. We keep only one value at a time in your sender record, plus the timestamp of the message we learned it from. Each weekly or monthly summary we generate also records the offset it was computed in — and the weekly one prints it in its heading — so those copies last as long as the summary does rather than being replaced. See the retention table below. A later message normally replaces it, and a message that turns out to be older than the one we already learned from is ignored, so mail arriving out of order can't quietly move your week. There is an exception worth naming: if a message reaches us stamped more than a day into the future — a mis‑set clock somewhere along the way, usually — we treat it as though it were stamped a day ahead of now, and correctly stamped mail arriving over the next day or so will look older than that and be ignored. So a wrong offset learned from such a message can stay in place for about a day after it arrives before ordinary mail can displace it — and if something in your mail path keeps stamping dates in the future, that can happen again each time. We would rather tell you that than describe the rule as absolute. - The currency your receipts are usually in. Recomputed once a week from the receipts already in your own history. It is used only as a last resort, when a receipt's own currency is genuinely ambiguous — several currency symbols are near‑identical in print. It is never used to convert an amount: we do not convert between currencies anywhere in this service.
When we send your weekly pulse or monthly review:
- The generated summary text itself.
- The outbound delivery record (sent / delivered / bounced — handled by AWS SES).
- Email‑open events from a 1×1 tracking pixel embedded by AWS SES Virtual Deliverability Manager (VDM). When your email client loads images, AWS SES records that the email was opened, along with a timestamp and metadata your client reveals when fetching the image (typically: an IP address, which AWS SES uses to derive approximate location, and user‑agent string). We use these signals to know whether summaries are landing and being read. You can block the pixel by disabling remote image loading in your email client before opening our emails — see Cookies and Tracking.
After you delete your account:
- Your subscription record is never deleted, only redacted: your address is overwritten with a one‑way hash. What's left includes that hash and a few dates — when you signed up, confirmed, when we last ran your weekly or monthly summary, and deleted. This is the durable audit trail to demonstrate the deletion happened. Plaintext of your email address doesn't stay in our live database beyond the deletion confirmation itself (backups aside — see below) — the one queue row carrying it is reduced to a hash within about 13 hours, whether or not that email has gone out yet.
- A short‑lived operational log entry (hashed address, timestamp) is also queued at the moment of deletion, for internal monitoring — normally written within moments, backstopped by the same retry mechanism as the rest of this process if it's ever delayed. It lives 7 days from when it's actually written, then ages out — it is not the durable record; the redacted row above is.
- Model‑invocation logs already written before your deletion continue to age out on their own 30‑day clock — see the retention table below.
- Database backups continue to age out on their own 7‑day clock — see the retention table below.
- Existing open‑tracking events continue to age out within 30 days; aggregated counts may persist longer — see the retention table below.
- If our system didn't confidently recognise your message as a receipt or one of the reply commands, a copy — including your plaintext address — may still sit in our contact mailbox. The same is true if you replied pause or resume before you'd confirmed your subscription: until you confirm, those count as a message to us, not a command. This is not time‑bounded like the items above: it stays until you ask us to delete it. It isn't reached by the deletion purge — email us and we'll delete it by hand. Forwarding to that mailbox does not wait for you to confirm: a message we couldn't confidently recognise, or a premature pause or resume, arrives there the same way even from someone who has never confirmed their subscription.
What we do NOT ask for or require:
- Bank credentials, credit card numbers, social security numbers, passport numbers, or other government IDs — we never ask for these and nothing in the service needs them. See below for what happens if one appears in anything you forward anyway.
- Hidden third‑party tracking pixels in our emails — the only open‑tracking signal is the AWS SES first‑party pixel described above.
- Cookies — we don't operate a tracked website.
- Browsing or device fingerprinting data, precise geolocation, or ad‑network identifiers. We ask for no location data and call no location API. Two coarse signals do reach us as a side effect of how email works, and we would rather name them than let the line above imply otherwise: the UTC offset stamped on the mail you send us, and the approximate location AWS SES derives from your IP address if your mail client loads our open‑tracking pixel. Both are described above.
One thing to be aware of. We process forwarded receipts as you send them, and PDFs you forward — statements included — usually go to the model to be told apart from a receipt, with the exceptions listed above. We do not scan for, strip, or mask sensitive numbers beforehand. If something you forward happens to contain a full card or account number or an ID number, it is processed and retained like the rest of that email — in the stored raw email for 30 days. If we send it to the model — which we usually do, but not for a password‑protected file, one larger than about 20 MB, or any after the tenth PDF we actually send from one message — then whatever AWS keeps of that exchange follows the 30‑day window described below. We'd rather say this plainly than imply a filter that isn't there. Please avoid forwarding documents that carry full card or ID numbers; if you send one by accident, email us and we'll purge what we can right away — the stored raw email and any parsed record. What's already reached the model‑invocation logs is not purged early; it ages out on the same 30‑day clock as everything else in those logs.
Why we collect it (lawful bases)
Under GDPR / UK GDPR:
| Data | Lawful basis | Plain‑language reason |
|---|---|---|
From: address, parsed receipts, generated summaries, user‑state record (including the locale signals above — your UTC offset and usual receipt currency) |
Art 6(1)(b) — contract performance | Necessary to provide the service you asked for: deliver summaries to the address you forwarded from, covering the day, week and month that just ended on the UTC offset stamped on the mail you send us, rather than always on UTC. |
| Full content of forwarded receipts | Art 6(1)(a) — explicit consent (your confirmation reply); Art 9(2)(a) for any special‑category data | You actively forward each receipt; your confirmation reply is explicit consent to model‑processing. |
| Full content of forwarded statements, and the records we will derive from them once statement reconciliation launches — after you confirm | Art 6(1)(a) — explicit consent (your confirmation reply); Art 9(2)(a) for any special‑category data | You actively forward each statement. If the confirmation email you replied to names statements, that reply is explicit consent to model‑processing them; if it doesn't, we're telling you here and by email instead. |
| Free‑text replies (commands and engagement) | Art 6(1)(b) for action‑classified replies; Art 6(1)(f) — legitimate interest for engagement routing | Acting on pause/resume/delete is the service; routing unclassified replies to the operator keeps the pilot honest. |
| Redacted sender record (one‑way hash + a few dates, no plaintext) | Art 6(1)(c) — legal obligation; Art 6(1)(f) — legitimate interest | Audit trail to demonstrate compliance with erasure requests if challenged. |
| Email‑open events from the VDM pixel | Art 6(1)(f) — legitimate interest | We need to know whether summaries are being opened to judge whether the pilot is working and whether to keep sending them. You can block the pixel by disabling remote image loading in your email client. |
If any forwarded receipt contains “special category” data (Art 9) — for example, a pharmacy receipt revealing a specific medication, or a religious or political donation — we do not name the specific item in your summaries, do not store it longer than the retention schedule below, and rely on Art 9(2)(a) explicit consent (your choice to forward it). A statement can carry the same kind of detail on any line, and more of it; once statement reconciliation is running, the same handling and the same basis will apply to statements you forward after confirming.
How long we keep your data
| Data | While active or paused |
After you delete | If pending‑confirmation expires |
|---|---|---|---|
From: address |
Until deletion | Purged within 24h of token confirmation | Purged at 14 days |
| Raw forwarded email body (incl. attachments) | 30 days from receipt, then truncated to parsed records | Purged within 24h — if that purge itself needs a retry, the same 30‑day‑from‑receipt clock every raw email already has is the backstop | Purged at 14 days |
| Statement PDFs (bank/card statements you forward) | 30 days from when we store it — the same 30‑day window the raw email gets. We store your statement as part of the email you sent, from the moment it arrives; what we don't do is write any statement record — header, lines, account — until your subscription is confirmed. The classifier read above still happens before then | Purged within 24h — and if that purge needs a retry, that same 30‑day expiry is the backstop | Purged at 14 days |
| What we extract from a statement — the issuer, the account type, its currency and country, the last few digits of the account number, the period, the balances and totals, each transaction line, any question we ask you about one, and the counts and totals we keep of how often we had to ask or got a line wrong. We are still building this; none of it is stored today — the classifier above does read a few signals out of the PDF, and, if you're receiving summaries and the check recognised the PDF as a statement, the reply we queue to tell you we can't process it yet carries the file's name — which on a bank export often contains your own name and the last digits of the account. That one reply is the exception: if you sent more than ten PDFs and photos we actually looked at, we answer with a single note about how many there were, and no filename travels at all. A signature logo or another tiny inline image doesn't count toward that ten, and nor does a file that is neither a PDF nor a photo. There is a second way no filename travels: if the check is unsure, or fails outright, we treat the PDF as a receipt, and a receipt draws no such reply. That queue row is deleted 7 days after we send it — in practice up to 8, because the sweep that removes it runs once a day. If we can never deliver that reply at all, the sweep never reaches it, because it only removes replies that went out: it stays queued, and goes when you delete your account. Beyond that reply, nothing from a statement reaches our database as a statement: no header, no line, no account, no reconciliation record. There is one way it leaves a mark anyway. If the check mistakes a statement for a receipt — the unsure‑or‑failed case above — we then read it as a receipt, and whatever the model finds in it is stored the way any receipt is, in the Parsed receipt records row below. Those are kept until you delete your account, like every other receipt. The two log rows near the bottom of this table are the rest of the story — the classifier's verdict and signals, and the trace of the check — and they are not nothing, which is why they have rows of their own. | Until deletion — unlike the statement PDF itself, these have no expiry clock of their own. The PDF is deleted after 30 days; what we extract from it stays until you delete your account | Purged within 24h of token confirmation | Purged at 14 days |
What you tell us about a line on a statement — that a payment labelled JSMITH PROPERTIES is your rent, who you were paying, or that a transfer between your own accounts isn't spending. Also still being built; we don't ask you about statement lines today |
Until deletion. These are your words about your own money, and they can name a landlord, an employer, or a family member. One that is later set aside as wrong is kept rather than erased — it still goes when you delete your account | Purged within 24h of token confirmation | Purged at 14 days |
| Parsed receipt records | Until deletion | Purged within 24h | Purged at 14 days |
| Locale signals derived from the mail you send us (your UTC offset and the timestamp of the message we learned it from; your usual receipt currency) | Until deletion — only the most recently observed value is kept in your sender record, though every generated summary also carries the offset it was computed in for as long as that summary is kept | Erased at redaction, within 24h of token confirmation, unlike the dates in the redacted record above. One caveat: in the ordinary case both of these also reach the model prompt for a receipt you forward, and that copy ages out with the model‑invocation logs further down this table rather than at deletion. Neither is guaranteed to, though: the usual‑currency hint is included only once we actually have one for you, and the send time is included only when we could read the header and it looked plausible | Purged at 14 days |
| Generated summaries | 12 months rolling | Purged within 24h | n/a |
| Email‑open events (AWS SES VDM) | 30 days from event, then auto‑purged. Aggregated metrics may persist beyond raw events per AWS defaults. | Existing events continue to age out within 30 days; no new events created after your 24h purge | n/a |
| Free‑text replies (command + engagement history — our database record of them) | Until deletion | Purged within 24h | Purged at 14 days |
| Contact‑mailbox copies of replies our system didn't confidently recognise as a receipt or a command, plus any pause/resume sent before you confirmed, and any message from someone who has never confirmed at all that our system read as engagement rather than as a receipt or a command — this reaches the mailbox before you have confirmed anything (plaintext address, subject, body, attachments — a separate copy from the row above, and read from Dubai; a recognised bank or card statement is held back, as is every attachment on an email that carried more than ten PDFs and photos we actually looked at, or a PDF we could open that ran to more pages or more bytes than we read, or one so large we never opened it at all) | Until you ask us to delete them | Not reached by the deletion purge — ask us and we'll delete by hand | Not reached by the 14‑day purge either |
| Pending deletion tokens | 24h TTL, then auto‑expired | n/a | n/a |
Redacted sender record (your email_senders row, address replaced by a one‑way hash) |
n/a | Retained — the row is never deleted, only redacted. A few dates survive (signup, confirmation, last summary, deletion); this is how we show the deletion ran. | n/a |
| Operational deletion‑log entry (hashed address + timestamp, for internal monitoring) | n/a | 7 days, then auto‑purged — short‑lived; the redacted sender record above is the durable one | n/a |
| Database automated backups (all your data as of the backup point) | Rolling 7‑day AWS RDS automated backup window | Existing backups continue to age out within 7 days of the backup date | Same |
| AWS SES inbound / outbound mail logs | Per AWS retention, configured to minimum | Aged out per AWS schedule | Same |
| Our own application log — when the check finishes, what the model reported back: whether the document looked like a statement, how confident it was, how many pages it had, and whether it showed an account number, a statement period, a transaction table or a bank's own branding. Those five signals are recorded as counts and yes/no answers, alongside the file's name hashed — never the issuer's name, and never any line the model quoted back. If the model fails or answers with something we can't read, we log that failure instead — none of the model's answers, though the page count stays, because we count the pages ourselves before sending it. The file's name is hashed in that entry too. Every other entry this log keeps about an attachment carries the name the same way — that we worked out its type from its contents, that we couldn't read it, that we dropped it. The name you gave the file is never written into this log in the clear. Written before you confirm, because the check itself happens then | 7 days from when the entry is written | Not reached by the purge — entries age out on their own 7‑day clock | Same |
| AWS X‑Ray traces — a timing record of each step handling your email, sampled at 100%. For the statement check it carries the same verdict and confidence as the row above, the page count, and the file's name hashed; elsewhere it carries step names and whether your subscription was active or paused. Your address rides along on most steps as the same one‑way hash the redacted subscription record above uses — not the address itself, but the same value, so a trace and that record can be matched to each other. A trace also carries the identifier your own mail program stamped on the message — usually a random string, but that program chooses it, and a few write an address into it. We don't put your message text or an attachment into a trace. What can carry a fragment of one is an error recorded on a trace: where the model's own answer could be echoed back into an error, we strip it, but we can't promise every error string anywhere in the system is clean | 30 days — AWS's own fixed schedule for X‑Ray. We don't set it and can't shorten it | Not reached by the purge — traces age out on their own 30‑day clock | Same |
| AWS Bedrock model‑invocation logs — the prompt and response for every model call, including forwarded receipt text and whatever AWS keeps of receipt photographs and PDFs — statements go to the model on the same path, so the same applies to them | 30 days from invocation, then auto‑purged. Not used to train any model. | Existing logs continue to age out within 30 days; no new logs created for you after your 24h purge, except one more entry if you email us again afterward — that message is classified before we recognise the account is deleted, which writes one more log entry either way. A non‑receipt message is then dropped without reply; one recognised as a receipt from its own subject and text starts a fresh subscription | Same |
To delete everything, reply to any email from us in plain English (“delete everything”, “I want out”, “wipe my data” — anything that reads as a deletion request works). We'll reply with a 6‑digit confirmation code; reply with the code within 24 hours and the purge completes within a further 24 hours, with confirmation in writing. The redacted sender record above is retained — not deleted — as the durable audit trail; a short‑lived operational log entry is also queued at the moment of deletion and normally written within moments; it's retained 7 days from that write, not from the deletion event. A few things the purge does not reach on the spot, and age out on their own clock instead: Bedrock model‑invocation logs (30 days), database backups (7 days), and open‑tracking events (30 days, though aggregated counts may persist longer) — see the retention table above. One thing the purge never reaches: a copy in our contact mailbox of anything our system didn't confidently recognise as a receipt or a command, including your plaintext address. A pause or resume you sent before confirming counts as a message to us too, so a copy of that is in there as well. That isn't time‑bounded, and only goes away if you ask us to delete it by hand. Beyond the operational log entry mentioned above, we log nothing new in the model‑invocation logs for you after deletion completes, with one exception: if you email us again, that message is still classified before we recognise the account is gone, which writes one more log entry either way. A non‑receipt message is then dropped without reply; a forwarded receipt starts a fresh subscription. We go by the email's own subject and text to tell it's a receipt; one sent as just an attachment with little else written may not be recognised.
Who we share it with
Three sub‑processors. The bulk of your data — forwarded receipts and statements, parsed records, summaries — stays within Amazon Web Services in the EU. A narrower flow involves Google Workspace, which hosts the operator's contact mailbox and receives any engagement messages the system can't auto‑classify. The public pages at monthaudit.com load fonts from Google Fonts, which means Google receives your IP address and browser headers on each page visit.
| Sub‑processor | Role | Where processed | Safeguards |
|---|---|---|---|
| Amazon Web Services, Inc. | Amazon SES for inbound and outbound email delivery; Amazon Bedrock for invoking Anthropic's Claude model (telling a statement from a receipt, receipt parsing, intent classification, summary generation); AWS compute and storage for everything else. | EU — Ireland (eu‑west‑1). Contracting entity is AWS, Inc., a US company. |
EU‑US Data Privacy Framework; UK Data Bridge; 2021 SCCs. Your data sent to Bedrock is not used to train any AI model — AWS Bedrock does not use customer prompts or outputs for training by default, and we have an AWS organisation AI services opt‑out policy in effect as a belt‑and‑suspenders measure. Invocations are not shared with Anthropic outside the request/response cycle. Bedrock invocation logs capture the prompt and response for every call — including forwarded receipt text and whatever AWS keeps of receipt photographs and PDFs — and are retained 30 days for operational debugging. They stay inside AWS. They are not reached by an account deletion; they age out on their own 30‑day clock. Our AWS RDS database also keeps rolling 7‑day automated backups, which likewise age out on their own clock rather than being purged on the spot. AWS DPA |
| Google LLC (Google Workspace) | Hosts the operator's contact mailbox (hello@monthaudit.com). Receives engagement replies the system can't confidently auto‑classify and forwards them to the operator for a manual response. Also receives any email you send directly to hello@monthaudit.com. | Workspace Data Regions configured to EU. Contracting entity is Google LLC, a US company. | EU‑US Data Privacy Framework; UK Data Bridge; 2021 SCCs. DPA |
| Google LLC (Google Fonts) | Serves the web fonts (Instrument Serif, Geist, JetBrains Mono) used by the public pages at monthaudit.com. Every page load sends your IP address and browser headers to Google's font servers. No receipt or account data is involved; only the page visit itself. | Google infrastructure (global CDN). Contracting entity is Google LLC, a US company. | EU‑US Data Privacy Framework. Google Privacy Policy; Google Fonts privacy FAQ. |
We do not use: any advertising network, retargeting pixel, analytics tool, data broker, third‑party cookie, or hidden third‑party email‑open tracking pixel. The public web surface is monthaudit.com — a static marketing page and this privacy notice. No signup form is operated.
International data transfers
The bulk of your data — forwarded receipts and statements, parsed records, summaries, and state — is processed within the European Union. AWS handles SES and Bedrock requests in eu‑west‑1 (Ireland) with storage in the same region.
- For EU users: no transfer outside the EU for receipt‑processing data. The contracting AWS entity is US‑based, but data residency is EU.
- For UK users: data moves from the UK to the EU (Ireland) for processing, relying on the UK's EU adequacy decision.
- For UAE, Singapore, Australia, and US users: data is transferred into the EU for processing. Equivalent cross‑border transfer mechanisms in your jurisdiction apply.
A separate, narrower flow involves Google Workspace (the operator's hello@monthaudit.com mailbox and engagement routing). Workspace Data Regions are configured to EU. For any incidental US‑bound transfer of Workspace data, transfers rely on:
- EU‑US Data Privacy Framework — Google is DPF‑certified. Verify current status at dataprivacyframework.gov.
- UK Data Bridge for UK residents.
- 2021 Standard Contractual Clauses.
One more leg, and it is the least visible from the outside. That mailbox's data region is set to the EU, but the person who reads it is in Dubai — so an engagement message routed to it is read from the United Arab Emirates, which has no EU adequacy decision. What travels that way is your address, the subject, and the body you wrote. An attachment usually travels too — a receipt photo, an invoice PDF. When our check recognises a bank or card statement, we hold the attachments back and the operator sees your message with nothing attached at all — not just the statement, everything that came with it. A statement we could not open, one our check read as a receipt, or that reached us as a photo, may not be held back, because nothing told us what it was. Nothing is attached either if the email carried more than ten PDFs and photos we actually looked at, or a PDF we could open that ran to more pages or more bytes than we read, or one so large we never opened it at all, or if the stored copy of your email has already aged out. The holding-back does not apply to mail you send to hello@monthaudit.com yourself: that arrives in the same mailbox, with whatever you attached, and is read the same way.
Your data sent to AWS Bedrock is not used to train any AI model. AWS Bedrock does not use customer prompts or outputs for training by default, and we have an AWS organisation AI services opt‑out policy in effect on top of that. Invocations are not shared with Anthropic outside the request/response cycle.
Email us for specifics for your location.
Your rights
Depending on where you live, you have some or all of the following rights:
- Access — you can ask what we hold about you and get a copy.
- Rectification — you can ask us to correct anything inaccurate.
- Erasure (“right to be forgotten”) — you can ask us to delete everything we hold about you (see deletion mechanic below).
- Portability — you can ask for your data in a machine‑readable format.
- Restriction — you can ask us to stop processing while a dispute is resolved.
- Objection — you can object to processing based on legitimate interest.
- Withdraw consent — where processing is based on consent, you can withdraw it at any time without affecting processing already done. Asking to delete everything has the same effect.
- Lodge a complaint with your local data‑protection authority — the UK ICO, the relevant EU Member State supervisory authority, the UAE Data Office, the Singapore PDPC, or the OAIC in Australia. We'd prefer you write to us first so we can fix the issue, but you don't have to.
To exercise any of these rights, including deletion: reply to any email from us in plain English. The system infers what you're asking for; you don't need to remember special keywords. For deletion, we'll send a one‑time 6‑digit confirmation code (single‑use, 24‑hour expiry) — this is to defend against an attacker who has spoofed your email address. Reply with the code and the purge completes within 24 hours, with confirmation in writing.
You can also email hello@monthaudit.com directly. We will respond within 7 days; for deletion requests, we'll confirm in writing once the purge is complete.
For California residents: you also have the rights described under the CCPA and CPRA, including the right to know, delete, correct, and limit use of sensitive personal information. We do not sell your personal information and have not done so in the past 12 months.
Cookies and tracking
We don't operate a tracked website, set cookies that identify you, or run analytics on the privacy‑notice page. The only web touchpoint is monthaudit.com hosting this notice, which uses no cookies and no analytics tool.
Our summary emails do contain a single 1×1 open‑tracking pixel, delivered by AWS SES. When your email client loads remote images, the pixel request reaches AWS, which records that the email was opened and the metadata your client reveals when fetching it (IP address, derived approximate location, user‑agent). We use this to judge whether summaries are landing — nothing more.
If you'd rather not be tracked, disable remote image loading in your email client before opening our emails. This is supported by every major mail client (Gmail, Apple Mail, Outlook, Fastmail, Proton) and typically lives under image‑display or external‑content settings.
Children
This service is not intended for anyone under 16. We do not knowingly collect data from children. If you believe a minor has signed up, email hello@monthaudit.com and we will delete the account.
Security
- All inbound and outbound email passes through Amazon SES with TLS 1.2+ encryption in transit where supported by the counterpart server. Everything you forward — receipts and statements alike — is encrypted at rest inside AWS.
- AWS access uses short‑lived IAM credentials following least‑privilege; no operator access to data held in AWS except via auditable IAM roles. That is scoped to AWS: the contact mailbox described above is Google Workspace, and the operator reads it directly.
- AWS Bedrock invocation logging is enabled with a 30‑day retention window for operational debugging. It captures request and response content — receipt text, and whatever AWS keeps of photographs and PDFs — not just metadata. Statement PDFs are sent to the model on the same path, so whatever AWS keeps of that exchange applies to them too. Access is IAM‑gated and audited. An AWS organisation‑level AI services opt‑out policy is in effect, on top of Bedrock's default no‑training posture.
- We do not ask for banking credentials, card numbers, or government IDs, and the service has no use for them. We do not, however, scan what you forward — receipts or statements — to strip such numbers if they happen to appear — see “One thing to be aware of” above.
- A monthly AWS budget cap is in place as a safety measure against runaway processing.
Changes to this notice
We'll update this notice when we add or remove a sub‑processor, change a retention period, change the legal entity, or add a new use of data. For material changes, we will email every user with an active or paused record at least 14 days before the change takes effect. For minor edits (typos, formatting), we'll just update the page and bump the “Last updated” date at the top.
The full version history of this notice is available on request.
Contact
Email: hello@monthaudit.com
Response time: typically within one working day, no later than 7 days for formal data‑rights requests.
Postal address: available on request to verified data‑rights requests.