Design Considerations

Legal and Regulatory Compliance

Before designing your notification service(s), be sure to take into account all related regulatory requirements and any rules that your partner bank may have in effect. For example, are you familiar with the CAN-SPAM Act? A full analysis is beyond the scope of this article. Please refer to your Q2 Expert and your banking partner for additional assistance.

Gaps in time

Any realtime notification system needs to contend with or be aware of a concept that, in this segment, we will refer to as "Gaps in Time." These are situations where an event occurs for a moment in the lifecycle of your Customer, but that for a variety of reasons the notification does not see final delivery to the Customer for some length of time after the moment.

Are events received over realtime guaranteed to be unique?

For a variety of reasons, the answer is no. For example, what if a service subscribed to the bus plucking off the message fails to .Complete() the event correctly and then, for a technical reason, the message does not move to the deadletter queue?

Is there a mechanism to reconcile what events I do or do not receive?

Yes, by importing the Event Notification file.

Who actually sends what?

Originating eventHelix PlatformHelix APIService Bus
Email to CustomerFinTech (You)FinTech (You)Customer
Toast Notification to CustomerFinTech (You)FinTech (You)Customer
Event Notification FileHelix PlatformHelixFinTech (You)

Do you have example content of what I should send Customers?

Yes! Contact us and we'll ensure we provide the relative examples.