Skip to main content

Real-time Workflow Considerations

The following sections provide common considerations to review when designing your solution.

Global URL Endpoint​

The Smart Alerts integration and setup requires each integrator to create and maintain only one URL endpoint to accept and process the Smart Alerts API messages. EPS Ensenta refers to this as a global URL endpoint. It is used to set up a global alert route on the integrator’s platform, through which all Smart Alerts API traffic for that integrator will flow.

Alert Volume​

This section is applicable for all alert event types.

The volume of alerts that your solution will receive over the course of the day is dependent on a couple main factors:

  • Which of the five alerts your solution is supporting (i.e., do you just support the single Deposit Alert Event, all five alert events, or other combination as outlined in section Alert Event Types Overview).
  • The volume of deposits the Financial Institution receives (depending on size, this could be as few as 0-100 deposits a day or 10,000+).

If your solution will support the “Deposit Approved – No Amount Adjustment” alert, there are a couple optional features that the Financial Institution may be leveraging that can potentially generate multiple alerts in a short time period:

  • One Click Approval: All eligible checks are approved by a single button click.
  • Auto-Approval: All eligible checks are approved based on one or more times defined by the Financial Institution (called the “Transmit Time”).

If there is any concern around volume of alert requests received throughout the day or within a short time period, please review the expected check volumes with the Financial Institution.

Days/work Hours of Proofing Staff​

This section is only applicable if supporting any of the four status alert event types:

  • Deposit Rejected
  • Deposit Approved – No Amount Adjustment
  • Deposit Approved – Amount Adjusted Up
  • Deposit Approved – Amount Adjusted Down
  • Batch Review Complete

When supporting any of the four Status Alert Events it is important to understand that they are only initiated when the status and/or the amount of the check are changed within EZAdmin by the Financial Institution (see section Multiple Status Alert Events).

Many Financial Institutions do not schedule proofing staff to review checks during evenings and weekends which could significantly delay when the Status Alert Event(s) are initiated in context of the original deposit being submitted (i.e., a check deposited on Friday evening may not be reviewed by the Financial Institution until Monday).

Auto-resend vs Duplicates​

This section is applicable for all alert event types.

When we do not receive a response for an alert event, we assume there was a transmission or connection error. JHA/Ensenta has automated functionality that will attempt to resend the alert event (see document Smart Alerts Exceptions Monitor User Guide - External for details).

Since it is possible that the alert event was successfully received by you but an issue prevented the response from being received by JHA/Ensenta, it is recommended to either:

  • Recommended: Include functionality to identify duplicate alert events within your solution to prevent alert events from being processed multiple times.

- OR -

  • Request JHA/Ensenta to disable the auto-resend functionality. The Financial Institution can instead manually review failed alert events within EZAdmin on the Smart Alerts Exceptions screen and manually re-send the alert (see document Smart Alerts Exceptions Page User Guide - External for details) or potentially handle outside of our system.

Exception Handling​

This section is applicable for all alert event types.

The following scenarios are considered exceptions:

  • No response is received
  • An error response code (any response code other than “00”) is sent in the response

The Financial Institution is responsible for reviewing and ensuring all exceptions are handled and processed appropriately.

JHA/Ensenta provides three methods for Financial Institutions to identify/review attempted alert events:

  1. The EZAdmin Alert Log screen logs all alerts (successful and unsuccessful) for research purposes. See document Alert Log User Guide - External for details.
  2. The EZAdmin Smart Alerts Exceptions screen only logs unsuccessful alerts and includes the ability to retransmit the alert if appropriate. See document Smart Alerts Exceptions Page User Guide - External for details.
  3. Every fifteen minutes, a service will look for any unresolved exceptions from the last fifteen minutes and send an email to the Financial Institution. See document Smart Alerts Exceptions Monitor User Guide - External for details.

Auditing/Balancing​

The Financial Institution is responsible for ensuring all alerts were received and processed appropriately.

JHA/Ensenta recommends your solution to include reporting that the Financial Institution can use to audit/balance against the JHA/Ensenta EZAdmin platform and/or any downstream processing application reporting (posting, notifications, or fraud).

Please work with the Financial Institution to identify any reporting requirements for your solution so they can perform the necessary auditing/balancing.

note

The most common method of daily auditing/balancing done by the Financial Institution through the JHA/Ensenta EZAdmin platform is to review checks included within their x9 file (total number of checks and total amount) against reporting from their item processing vendor (what they received and processed).

The x9 file contains all checks that were approved by the Financial Institution within a defined cutoff time window (defined by the Financial Institution). Consider reviewing the defined cutoff time(s) with the Financial Institution (they may have multiple cutoff times per day) and leverage the same cutoff time(s) in your reporting solution for easier auditing/balancing.

Queuing​

This section is applicable for all alert event types.

Depending on the downstream processing application that your solution is interacting with, it is possible that there may be extended periods of time where your solution is up and running, but the downstream application is down on a regularly scheduled basis. An example of this is for different Core systems where they may have a “night” mode for nightly balancing/auditing and is unavailable to interact with during this time.

It is recommended that your solution have some method of queuing in place to ensure that all alerts are processed as early as possible. Here are a couple of solutions that vendors have developed to accommodate unavailability from the downstream application:

  • During normal operating hours, process the alert in real time. During the scheduled downtime for the downstream processing application, provide a successful response to JHA/Ensenta (response code “00”) indicating that the alert was received and then queue the alerts within your solution to process with the downstream processing application when it is back online.
  • A simplified approach is to always provide a successful response to JHA/Ensenta (response code “00”) for all alerts indicating that the alert was received and then queue the alerts within your solution to process with the downstream processing application separately.
    • The negative aspect to this type of queuing is that your solution would never be able to provide meaningful error response codes to JHA/Ensenta if there is an issue processing the alert with the downstream processing application. Most troubleshooting by the Financial Institution will be through error logging within your solution as it would look like a successful alert from the JHA/Ensenta side.

While JHA/Ensenta has some automated and manual alert retransmitting capabilities, it is the best practice to primarily rely on this for downtime with your solution versus regularly scheduled downtime from the downstream processing application. See section Auto-resend vs Duplicates and the Smart Alerts Exceptions Page User Guide - External document for more information.

Multiple Status Alert Events​

This section is only applicable if supporting any of the four status alert event types:

  • Deposit Rejected
  • Deposit Approved – No Amount Adjustment
  • Deposit Approved – Amount Adjusted Up
  • Deposit Approved – Amount Adjusted Down
  • Batch Review Complete

Once a check is Rejected or Approved for the first time (meaning one of the above alerts would have been sent), the Financial Institution is able to update the status (Rejected/Approved) and/or the check amount up until a time defined by them (called the “Transmit Time”). Each time the Financial Institution makes an update to a check (status and/or amount), an alert request is sent. (except Batch Review Complete)

Your solution will need to either:

  • Support processing the subsequent alert requests for a check when updates are made.

- OR -

  • Only process the initial Status Alert Event request and define Standard Operating Procedures with the Financial Institution to ensure that they have a process for manually handling any updates to a check that has already been Rejected/Approved.

- OR -

  • Support the Batch Review Complete alert event request for a deposit after it has been reviewed.