Real-Time Banking Alerts and Consent Separation in Emarsys

Use Interactions for the real-time alerts, not Automation Center. Automation Center is designed for scheduled or segment-driven journeys and is a poor fit for a 60-second contractual alert with a per-event payload. Interactions accepts external events and can send an immediate transactional message keyed to the contact, which matches card declines, transfers, password resets, and unusual-login notices. Automation Center can still handle marketing follow-ups, such as a security education series, but it should be triggered separately and must respect marketing consent. Keep the alert template and the promotional template distinct so an alert is not suppressed by a marketing opt-out. Confirm that the Emarsys contact exists or can be created from a stable identifier before sending, and test latency under load. The reasoning is that channel choice follows the service-level requirement and the legal nature of the message, not internal team convenience.

One contact record is acceptable if consent is modeled as separate purposes: transactional/service, marketing email, and possibly channel-specific marketing. The alert send path should check service eligibility, not marketing opt-in; the promotional path should check marketing consent and suppression. Never let an alert silently opt a customer into marketing. For data minimization, remove the account number from the event payload and from any Emarsys field; use a tokenized customer reference and include only the minimum detail needed to render the alert-such as masked card ending, amount band, or a secure link. Device IP should be dropped unless there is a documented fraud requirement and an approved retention rule. Log consent version, source, and timestamp outside the message content, and ensure the alert template does not expose sensitive data in the subject line. The reasoning is that reusing a record is a data-model decision; it does not justify reusing consent or over-collecting personal data.

A one-second retry loop for five minutes creates up to 300 duplicate attempts per event, amplifies any Emarsys or network incident, and can produce duplicate alerts or rate-limit blocks. It also ignores the possibility that the first call succeeded but the response was lost. Recommend an asynchronous queue between the mobile app and Emarsys: the app submits once, the queue handles delivery, and retries use exponential backoff with jitter and a bounded attempt count. Include an idempotency key per event so repeated delivery does not create duplicate sends, and define a dead-letter path for failures. Monitor latency against the 60-second target and alert on queue depth. Test duplicate submission and partial failure explicitly. The reasoning is that transactional reliability comes from controlled retries and idempotency, not from aggressive client-side retry loops.