OptionalachName?: stringThe entity's own beneficiary names, as they appear on an INCOMING payment (docs/BENEFICIARY_NAMES.md). Optional because the producer may predate them; copy that uses one must guard it.
OptionalwireName?: stringOptionalachName?: stringThe entity's own beneficiary names, as they appear on an INCOMING payment (docs/BENEFICIARY_NAMES.md). Optional because the producer may predate them; copy that uses one must guard it.
OptionalwireName?: stringOptionalmissingDetails?: stringA sentence naming the details the recipient lacks (ACTION_REQUIRED).
Optionaldate?: stringTransaction date, preformatted for display.
Optionalimad?: stringOptionalmemo?: stringDescription / transaction notes (FFC memo for wires).
Optionalomad?: stringOptionalreference?: stringReference number (IMAD for SWIFT wires).
OptionalsenderName?: stringOriginator / name of sender. For SWIFT deposits with no originator on the wire this is "Originator not specified" (ENG-2911).
OptionalachName?: stringThe paying entity's own beneficiary names (docs/BENEFICIARY_NAMES.md),
for copy naming how the payment appears to the payee. Never the payee's
own name — that is paymentInstrumentName.
Optionalimad?: stringOptionalomad?: stringOptionalwireName?: stringOptionalsenderMessage?: stringOptionalsourceCustomerName?: stringMay be omitted: a cross-customer transfer resolves only one side, and the counterparty ledger account may have no public projection visible to this customer — the transfer path drops the field for that case rather than sending an empty string (ENG-3003), so copy has to read correctly without it.
OptionaltargetCustomerName?: stringMay be omitted, as sourceCustomerName.
The day the email is sent, in the billing timezone: the charge follows it.
The invoice's id.
CFX-YYYYMMDD-NN.
Issue date in the billing timezone, preformatted, e.g. Nov 1, 2026.
The billing month, e.g. November 2026.
The account the fee is debited from.
The monthly platform fee's invoice, mailed before the fee is taken.
The invoice's id.
When the transfer settled, in the billing timezone, preformatted.
The receipt for a settled platform fee, naming the invoice it pays.
On-chain signature of the fee transfer.
Cognito's own mail, sent by email-notification-handler as the platform and
bank pools' Custom Email Sender. status is the trigger source.
The code, or ADMIN_CREATE_USER's temporary password.
The recipient, which is also the username a temporary password signs in with.
No code: Cognito's event carries none, so copy must not use one.
A self-serve application's progress, sent to its workspace's members by
email-notification-handler from customer.application.statusUpdated.
The business name the applicant gave.
The application's status page; the dashboard's sign-in once APPROVED.
The email notification payload union: one member per code-registered template key, carrying the merge variables that key's copy may interpolate.
This is the shape the event-driven sender builds each notification from — the lambda resolves recipients through
CustomerNotificationServiceand renders these payloads through itsb2b.email_templatetemplates.Hoisted out of
sendso the email template registry can derive its condition vocabulary from it (see./schema/email_template.ts) without a circular type alias — the registry's key type comes from this union, and the sender's signature comes from the registry.Lives in
dbrather thannotification-servicesbecause the registry it feeds sits next to theb2b.email_templatetables it seeds, and those tables'templateKey/statusVariantcolumns are typed from it. Pure types, sonotification-servicesre-exports them from here at no runtime cost and the eleven sending services import the same names as before.A template can only interpolate variables a sending app actually provides, so this union is the authority on the vocabulary. Adding a merge variable is a change here plus a change in every sending app that builds that member.