When a restrictive entitlement is configured, users must be configured to have that entitlement before they can view the entitled data. The outbound physical transmissions page incorrectly restricts the data based on the inbound data fields. So, nonentitled users have a more restrictive view of the outbound physical transmission page.

When FTM processes Zelle payments, multiple Web Service API calls are made to Early Warning Services (addPayment, updatePaymentStatus, and so on) that can encounter SOAP faults during communication. When these faults occur, FTM does not know the "real" status of the payment as known by EWS. The SOAP fault could occur before EWS ever got the API call. Or, EWS received the message and the SOAP fault occurred during the response. So, the payment could be in various states with EWS.

FTM marks these payments as Out of Sync (OOS). Previously, these OOS payments were handled by using the cancel menu option to cancel the payments individually. Or, they were handled by running a Services Framework task that searches the payment table for OOS payments and attempts to resync those payments.

The new implementation ties the OOS Zelle payments into the FTM retry framework to facilitate automatic retries of Zelle OOS payments as they occur and attempt to resync the payments automatically.  Also, more resync logic was added for outbound payments that allows FTM to be more intelligent about how it handles those OOS outbound payments.  With this new logic, the only OOS outbound payments that are cancelled are the payments that were never received by EWS (SOAP fault occurred on the API call) or the payments that were cancelled at EWS (possibly by the receiver).  Otherwise, if the outbound payment exists at EWS, FTM resyncs the payment and continues processing (notifications, distribution, and so on) from where the SOAP fault condition occurred.

The Zelle OOS payments use the existing FTM retry framework by assigning a known error code (configured in Administration -> Components -> Zelle -> General properties) to the OOS payment.  New Business Rules retry configuration details dictate how often, how long an OOS payment with the assigned error code, and the specific retry category (ZELLE_OOS) are retried.  The existing Services Framework RetryTask needs to be configured with the specific ZELLE_OOS category and ZELLE payment scheme.  Schedule the RetryTask to run as the customer wants.  When it runs, the RetryTask causes the OOS Zelle payments to be resynced with EWS.  The process continues until the OOS payment is correctly processed or the retry attempts are exhausted.

A new multi-select “Zelle Resync” menu option was added to the transactions grid page.  This option allows multiple selections of transactions if all that are selected are Zelle payments AND Out of Sync.  This option allows manual resync actions for permissioned users outside the automated retry framework.

EWS introduced a new token type in addition to email and mobile.  The new token type is Zelle tag (zelletag token type).  A Zelle tag must meet the following validation criteria:

• Is not case-sensitive.
• Must be equal to or greater than 6 characters in length
• Must be equal to or fewer than 40 characters in length
• Must contain only alphanumeric characters and hyphens
• Must not contain a set of single repeating characters, ignoring dashes
• Must not contain all numeric characters, ignoring dashes

The Zelle tag token allows customers to give out generic Zelle tag tokens for payments and payment requests instead of exposing their email address, mobile number, or both.  After it is registered, a Zelle tag token is processed as an email or mobile token within the various payment flows.

The Zelle tag does provide a level of privacy for a customer since they do not need to provide their email address, mobile number, or both to send and receive Zelle transactions.  However, EWS does require that a Zelle tag token has a Zelle contact method.  This contact method does need to be a verified (done by the mobile app) email address or mobile number.  This contact method must adhere to the same rules as email and mobile Zelle tokens as far as they must be:

• Valid – The mobile app does validity checks just as it does when the contact method is used as a token
• Not a restricted Zelle token

The Zelle Contact Method can be a registered Zelle token but is not required to be.  The Zelle contact method cannot be a restricted token.  If the Zelle contact method becomes disconnected or is restricted, EWS notifies FTM that an updated Zelle contact method must be provided for the affected Zelle tag.

The following new Liberty web service APIs were added to support:

1. Get the status of the contact method token at EWS (GET /{ftm_participant_id}/tokens/{token}/ews_status)
   The registered participant requests the status of the provided token.  FTM responds with the token information that is known by EWS (if the token is registered at EWS).
2. Available profile check (POST /{ftm_participant_id}/tokens/available-profiles)
   This API is provided with various data fields: type(PERSON/BUSINESS), first/business name, last name, requested Zelle tag name, contact method. FTM gathers information from EWS detailing:
   • Availability of the requested Zelle tag.
   • Alternative Zelle tags that are available and can be used
   • The EWS status of the contact method (if provided). This status is the same data that is contained in the GET web service API.
3. Update a Zelle tag contact method (POST /{ftm_participant_id}/tokens/{zelle_tag_token}/zelle-tag-contact)
   Use this API when the contact method for the Zelle tag needs to be updated.
    

The CXCToken web service APIs were updated to allow for Zelle tag token creation.  These updates include a new tokenType ('Z') and a new zelleTagContactMethod parameter.

More specific details about these web services, including YAML files and workflow diagrams, are included in the entitled documents.

To comply with EWS support of Zelle tag management, FTM supports the OnContactMethodWarning4.3 EWS notification.

The following new notification user exit methods were added.

• sendUpdateZelleTagContactMethod

  This notification is sent when FTM receives an OnContactMethodWarning notification to inform the user that an update their Zelle contact method is needed.

• sendZelleTagContactMethodUpdated

  This notification is sent when the user successfully updates their contact method by using the POST /{ftm_participant_id}/tokens/{zelle_tag_token}/zelle-tag-contact web service API.  This notification ensures that the user is aware that their Zelle tag token now has a new or different contact method.

The initial notification sent to a customer to update a Zelle tag contact method is sent when the EWS notification is initially received. A new ZelleTagContactMethod Services Framework task is created to send any further reminders to the customer to update their contact method. When it is run, the task looks for any Zelle tag tokens that require an update to the contact method.  For each of these tokens, the task calls the new sendUpdateZelleTagContactMethod notification user exit API method.  The user exit is able to define how often the participant is notified based on the current time and the timestamp of when the update was requested (every 5^th day, the day before, and so on).  The sample notification user exit provides examples of how to accomplish this participant notification.

The EWS WSDLs were upgraded to the EWS 4.4. level. Not all APIs were upgraded to the latest versions. The upgrade to the new WSDL version allows for future API updates as they are needed.

Revalidated TCH RTP v2.10 Certification for FTM based on the new rules published October 2021 and effective January 2022. Validation was done by using the latest Certification Tool from TCH. FTM is compliant.

EWS provided new “Zelle Risk Services” to participants by their ValidateRecipient web service API.  The Zelle Risk Services provides varying checks on the recipient token that is being processed and returns the varying data points from those processes in the ValidateRecipient response.

FTM includes the requested risk evaluations to EWS on the ValidateRecipient web service API. The returned risk information is stored and is provided to the customer’s fraud user exit.  The customer’s fraud user exit is tasked with interpreting the returned results as needed.  Risk documentation from EWS provides further details about the contents of the data that is returned and how it is to be interpreted.

The risk evaluations and evaluation results are not provided on any read web service API and are not displayed on the transaction details user interface.

The CXCPayment, CXCPaymentRequest, and ZellePaymentRequest web service APIs were updated with a new (optional) riskEvaluations parameter.  The riskEvaluations field is a set of evaluation strings (maximum of 5) that are included in the ValidateRecipient EWS API call.

More specific details about these web services, including YAML files and workflow diagrams, are included in the entitled documents.

If you want to process the ZelleRiskEvaluations and ZelleRiskScores that are provided by EWS, your Zelle fraud user exit needs to be updated. These fields are available on the CXCPayment data object that is provided to the fraud user exit.

Migration