"Sent" is the most dangerously ambiguous word in document distribution.
When an operations team confirms that the quarterly statement run is "sent," they might mean the generation job completed. Or that the email job triggered. Or that the SMTP server accepted the messages. Or that recipients received the emails in their inboxes. Or that customers opened and read their statements. Each of these is a different claim, and only some of them can be proven.
For a general business communication, this ambiguity is harmless. For a legally required investor statement or a regulatory filing, it matters enormously. If a regulator or a customer asks for proof that document X was delivered to recipient Y on date Z, "the job ran successfully" is not the same answer as "SMTP acceptance was logged for recipient Y at 14:23 on 31 March."
This article explains what the levels of delivery evidence actually are, why different document types require different levels of proof, and what a delivery tracking process for regulated batch distribution needs to capture.
The Four Levels of Delivery Evidence
Organisations running batch document distribution typically operate at the first or second level and treat it as equivalent to the fourth. It is not.
Level 1: Job completion. The batch generation and email job completed without system errors. This proves the system ran. It does not prove that any recipient received anything. A job that completes successfully and delivers to 4,800 of 5,000 recipients is, from the system's perspective, a success.
Level 2: SMTP acceptance. The sending SMTP server transferred the message to the recipient's mail server, and received an acceptance acknowledgement. This is the point at which responsibility formally transfers from sender to recipient mail infrastructure. It proves the message left the sender's control and was accepted by the receiving server. It does not prove the message reached the inbox — the recipient's server may have quarantined it, routed it to a spam folder, or later bounced it.
Level 3: Inbox delivery. The message reached the recipient's inbox. This is typically not provable through SMTP alone. Email open tracking (embedded pixels) provides a signal, but it is not reliable — recipients disable tracking, email clients block it, and a read receipt is not a legal proof of receipt.
Level 4: Confirmed receipt. The recipient has acknowledged receiving the document — through a read confirmation, a portal login that retrieved the document, a signed acknowledgement, or a regulatory submission system that confirms the filing was received. This level of proof is rare in mass distribution but is required in specific regulatory contexts.
Most batch statement runs operate between Level 1 and Level 2. Knowing where you actually are — and where your regulatory obligations require you to be — is the first step in building a delivery tracking process that protects the bank.
Why the Level of Proof Required Varies by Document Type
Not all documents in a bank's distribution portfolio carry the same delivery obligation.
Standard client communications — marketing materials, informational updates, service announcements — generally require that the bank made a reasonable attempt to deliver. SMTP acceptance, combined with a valid address drawn from the customer record, typically satisfies this standard.
Periodic regulatory investor statements — quarterly portfolio statements, annual account summaries, fund valuations — are legally required communications. The bank is obligated to send them to every qualifying investor. For these, the delivery record needs to demonstrate that the attempt was made per recipient, that the address used was the one on record, and that failures were identified and followed up. Per-recipient SMTP acceptance records are the minimum defensible standard.
Term change notifications and rate change notices — event-triggered documents notifying customers of changes to product terms — carry a notice period obligation. The bank must be able to prove not just that the notification was sent but that it was sent within the legally required notice window. The timestamp of the SMTP acceptance record for each recipient becomes evidence that the notice period was met.
Regulatory filings — documents submitted to regulators, central banks, or supervisory authorities — typically require confirmed receipt at Level 4. The regulator's submission system issues a confirmation reference number or a timestamped receipt. This is the authoritative delivery record, not the SMTP log.
Legal letters and demand notices — formal correspondence with legal standing — may require registered delivery or documented attempts in jurisdictions where electronic delivery has specific requirements. The delivery tracking for these documents should be designed with legal counsel, not inferred from standard email distribution practices.
Per-Recipient Tracking: What It Means at Scale
A batch distribution of 5,000 statements has 5,000 individual delivery events. Tracking "the batch ran" is not per-recipient tracking. Per-recipient tracking means the delivery record associates each document with the specific recipient it was sent to, the address it was sent to, the timestamp of the attempt, and the delivery outcome.
This has three operational implications:
Failures become visible and actionable. In a batch without per-recipient tracking, a 2% failure rate — 100 failed deliveries in a 5,000-statement run — may not be noticed until customers call to report they didn't receive their statement. With per-recipient tracking, the 100 failures appear in the delivery log immediately after the run, attributed to specific accounts with specific failure reasons (invalid address, mailbox full, domain not found). The operations team can act on them before the deadline for regulatory delivery has passed.
Partial reruns are possible. When failures are tracked per recipient, only the failed accounts need to be rerun. Without per-recipient records, rerunning the delivery for failed accounts requires manually identifying who didn't receive their document — a process that is slow, error-prone, and typically incomplete.
Individual delivery confirmation is available on demand. When a customer calls to say they didn't receive their statement, or when a regulator asks whether a specific investor received their required filing, the delivery record for that individual account should be retrievable in seconds. "Account 14582 — delivery attempted 31 March 14:23 — SMTP acceptance confirmed from mail.recipient.com" is a complete and immediate answer.
Delivery Failures as Compliance Events
For standard business communications, a delivery failure is an operational problem. For regulated documents, it is a compliance event — and the response needs to be documented accordingly.
The failure categories that occur in large-scale regulated distribution are predictable:
Invalid or outdated address. The address in the customer record is no longer valid. The message bounces. The bank's obligation is to have a process for maintaining current addresses, and a documented follow-up procedure for delivery failures — which may include attempting delivery through an alternative channel, or contacting the customer to update their address.
Mailbox full or temporarily unavailable. The receiving server accepted but was unable to deliver, or returned a temporary failure. This requires a retry protocol with defined timing, and a failure escalation if retries are exhausted.
Domain or server unreachable. The recipient's domain cannot be reached. For institutional investors or counterparties with corporate email domains, this may indicate a change in the counterparty's infrastructure. The failure requires investigation, not just a retry.
Spam filtering or quarantine. The message was accepted by the receiving server but filtered before reaching the inbox. This is frequently invisible in SMTP-level tracking — the server accepted the message and returned a success code. Detecting this class of failure requires either recipient confirmation (Level 4 evidence) or periodic review of unread documents against expected engagement levels.
In each case, the documented response matters as much as the failure itself. A regulator examining a delivery failure wants to see not just that the failure occurred but that it was identified, escalated appropriately, and resolved within a reasonable timeframe. The delivery tracking record, combined with the remediation log, is what constitutes a defensible response.
The Delivery Metadata Record: What to Capture
A complete delivery tracking record for each document in a regulated batch run needs to capture enough information to answer any subsequent inquiry without going back to source systems. For each recipient, the record should include:
- Document identifier: a reference linking the delivery record to the specific document version delivered
- Recipient identifier: the account or customer reference — not just the email address, which may change
- Delivery address: the address the document was sent to, at the time it was sent
- Attempt timestamp: when the delivery was attempted
- Delivery outcome: SMTP acceptance, bounce code and reason, or other terminal status
- Retry history: if applicable, the timestamps and outcomes of retry attempts
- Final status: delivered, failed-with-follow-up, or failed-unresolvable
- Remediation reference: if follow-up action was taken, a reference to the record of that action
This record lives in the bank's delivery operations layer — the process and tooling that sits around the report generation and distribution platform. It is not automatically created by the generation platform alone; it requires deliberate design in the operational process.
Returning Delivery Status to Upstream Systems
For statement runs orchestrated by an upstream system — an investment management platform, a workflow engine, a fund administration system — delivery status needs to flow back to that upstream record.
The investor account record in an investment management system is the authoritative source of truth for that customer's history with the bank. If the quarterly statement run completed with 98 successful deliveries and 2 failures, the account records for the 2 failed deliveries should reflect that status, not simply show "statement sent" based on the batch trigger event.
This feedback loop closes the audit trail. The investment management system's record for account 14582 shows: statement generated on 31 March (reference: batch-Q1-2026-v1), delivery attempted to address on file, SMTP failure (invalid address), follow-up initiated by operations team on 1 April, corrected address confirmed, redelivery completed on 2 April. That chain of events, captured in the upstream record, is the complete compliance record for that investor's quarterly statement.
The mechanism for this feedback varies by architecture. In some implementations, the batch distribution platform posts delivery status events that the upstream system consumes. In others, the operations team manually updates delivery outcomes after the batch completes. In either case, the principle is the same: the upstream record of each investor account should accurately reflect what happened, not just what was intended.
How CxReports Supports Delivery Tracking
CxReports provides the generation, scheduling, and distribution infrastructure; the delivery tracking layer sits around it, capturing and managing the per-recipient outcome records.
Per-job execution logs. Every email job run in CxReports is logged with a timestamp and execution status. Scheduled jobs maintain a history of when each run occurred, providing the baseline record of when distribution was triggered.
Per-recipient batch item tracking. For batch runs, CxReports tracks the status of individual items — generation success or failure per account, and delivery attempt status per recipient. Failed items are identified in the job status view with failure reasons, allowing the operations team to address exceptions without processing the full batch again.
Data-driven recipient lists. Recipient addresses are drawn from the same data source that feeds the report parameters. The address used for each delivery is the address in the data at the time of the run — creating a clear link between the recipient record and the delivery attempt that can be referenced in any subsequent inquiry.
API integration for delivery status feedback. For upstream systems that need delivery outcomes, the CxReports API enables programmatic interaction with the platform — triggering generation, retrieving status, and building the delivery metadata flow that feeds back into investment management or workflow platforms.
Separation of generation and distribution. The generation step and the distribution step in CxReports are not automatically chained. This creates a natural point for the pre-distribution review (consolidated review before distribution is triggered) and supports the operational model where distribution requires an explicit approval action after generation is confirmed correct.
What CxReports does not replace is the bank's own delivery metadata record — the per-recipient log that captures SMTP outcomes, retry history, and remediation actions. Building that record, and the operational process around it, is the bank's layer. CxReports provides the generation, the distribution trigger, and the item-level status that feeds into it.
Getting Started with CxReports
| Delivery tracking requirement | CxReports capability |
|---|---|
| Record of when each distribution job ran | Email job execution history (timestamp per run) |
| Per-recipient generation and delivery status | Per-item batch tracking (success/failure per account) |
| Data-driven recipient addresses from account records | Email data source with email addresses source enabled |
| Staged generation and distribution | Generation and email jobs triggered independently |
| API integration for delivery status feedback to upstream systems | CxReports API (GET /api/v1/ws/{workspaceId}/reports/{id}/pdf, email job endpoints) |
Documentation:
If you are designing the delivery tracking and compliance record for a regulated statement distribution workflow, book a demo to discuss how per-recipient tracking and API integration support your evidence requirements.