A 1.2 Million Regulatory Notice Against a Pressure Rule
A bank must send a regulatory notice to 1.2 million recipients inside an 8-hour window. The delivery template routes through a mid-sourcing server with four sending IPs; measured throughput on comparable campaigns is 90,000 messages per hour. The instance's typology contains a pressure rule on the recipient dimension: maximum 2 messages per recipient per rolling 7 days, action Reject, applied to all email deliveries. In the same week, three marketing campaigns target an overlapping population of 400,000 recipients. A dry run of the notice shows 480,000 recipients excluded at analysis. Marketing insists the notice cannot slip, and compliance insists every customer receives it exactly once with a working opt-out.
1. Assess the 8-hour window with the stated numbers and set out the options in order of acceptability.
Read the worked answer
1,200,000 divided by 90,000 per hour is 13.3 hours before any overhead. The window cannot be met on current capacity, so the first task is to say so plainly and quantify the gap - about 5.3 hours, or roughly 480,000 messages.
Options, best first.
- Add sending capacity. A second routing or additional IPs on the mid-sourcing server. This is the only option that changes throughput rather than the promise. Verify reputation impact: new IPs must be warmed and the ramp-up itself costs time, so this is not a same-week fix unless capacity already exists.
- Re-measure the throughput figure. 90,000/h is only valid for the payload size and personalization complexity it was measured on. A heavy template with conditional blocks and an API call in the body can halve it. Re-measure on a 50,000 sample with the real content before planning.
- Move the start earlier if the legal window allows an 8-hour 'from start of day' interpretation. This is a negotiation with compliance, not a technical decision.
What does not work: splitting into waves on the same single routing. Waves sequence the work, they do not shorten the total time - 1.2M at 90,000/h remains 13.3 hours however you slice it.
2. The pressure rule excludes 480,000 recipients. Explain what the rule is doing and how you legitimise the notice without breaking the marketing rules.
Read the worked answer
What is happening. Pressure rules are evaluated at analysis, before the target is finalised. The rule counts messages already sent to the recipient in the rolling 7-day window and rejects the message when the count is reached. The 480,000 are contacts who already received two emails this week; they are removed from the target and never addressed, which for a regulatory notice is a compliance failure as well as a data problem.
The wrong fix is to disable or loosen the rule globally: it protects every other campaign in the instance.
The right fix is scoping. Give regulatory and service messages their own delivery nature or folder, and filter the pressure rule so it applies only to marketing natures. The notice is then outside the rule while the three marketing campaigns still see the full pressure arithmetic across their own population.
Two things to document.
- A delivery-level exclusion of a typology rule is also possible and is faster, but it is per-delivery, invisible to the next person who reuses the template, and unauditable at scale. Prefer the scoped rule.
- Decide explicitly whether the notice should count toward the pressure seen by the marketing sends later that week. If the rule only counts its own scope, it will not. That is a reputation and compliance decision, not a technical one - record it.
Test by re-running the analysis on the notice and on one marketing campaign after the change, and compare target sizes.
3. Compliance requires exactly one message per customer plus a working opt-out. What controls do you put around the send, given that the previous dry run already excluded part of the population?
Read the worked answer
Freeze the population. Extract the 1.2M target into a persistent work table (or an export) at a known timestamp and treat that snapshot as the legal record. Every subsequent count is compared against the snapshot, not against a live query whose result shifts as data changes.
Prove exactly-once. Deduplicate on the recipient internal id, not the email address - shared mailboxes are legitimately duplicated and one message per mailbox is not the same as one per customer. Then reconcile after the send: delivery logs distinct recipient count versus snapshot count, and any difference explained line by line.
Opt-out. The link must be present and functional; verify it on a real send, not only on a proof, because the unsubscription URL is built from the delivery's declared unsubscription web application and will silently produce a dead link if that binding is missing on the template. Confirm the opt-out writes to the right schema and is honoured by the following campaigns.
Message type. Declaring the delivery as a service or transactional-type message affects which typology rules and which unsubscription mechanisms apply. That classification is a compliance decision that must be agreed in writing before the send, because changing it later changes the target and the audit trail.