Smart Payment Execution Date - Mass Payments Requirements

This RFC describes the solution for including additional requirements for improving accuracy of payment execution date calculation using Smart Date service.

Background

Smart Date service has been implemented following RFC: Smart Payment Execution Date

The main focus of the solution provided in the above RFC is calculating execution date depending on the holidays of the countries involved in payment execution, cut off time and number of days to complete the payment.

Holidays were identified based on the provided payment source and destination countries, whereas cut off time and number of days was identified based on the payment currency and corridor.

Corridor is an entity which is not defined enough in previous RFC, so there are still opened questions, like:

  • What does corridor represent

  • How do we distinguish between different corridors

During implementation, we recognized that the corridor should be representing a combination of Payment Instrument (swift, sepa, fps) and Intermediary Bank (Barclays UK, Citibank, etc.).

During the implementation of the integration of Smart Date service into multi payment workflow for Mass Payments, we received feedback from Mass Payments Team that execution date calculation Smart Date service is currently performing is not accurate enough for automating current manual processes around execution date calculation. Thus, we received new requirements on how to improve the service to make it more accurate.

Problem

Smart date service accepts following parameters for calculating execution date:

  • payment source country
  • payment destination country
  • payment currency
  • corridor
  • expected delivery date

Within its configuration, Smart Date holds information about:

  • holidays (and weekends) per countries
  • cut off times and days to complete payment per corridor and currency

Couple of issues have been identified during implementation of the integration:

  • There are no clear instructions on how to differentiate between different corridors, should we have more than one. And if we take into consideration what corridor represents, it is expected to have more than one corridor

  • Cut off times and days to complete payment depend on more parameters apart from corridor and currency. It may also depend on destination country.

  • Intermediary countries' holidays (involved during payment execution) are also taken into consideration when calculating dates (apart of source and destination countries), however, they also depend on destination country, which is currently not implemented.

There is an ongoing project that should address some of the above issues: Payment Scheme Data Service. Depending on various payment parameters, the service should identify possible routes payment would take and respective bank intermediary, which would be used by Smart Date service to accurately calculate execution date. However, at the time of this RFC, the project is not in its final stage, so we are not be able to use it now.

Therefore, we need an intermediary solution that will enable Mass Payment integration into the Ebury Core system and automation of payment execution date calculation.

Solution

Requirements

To make execution date calculation accurate for Mass Payments, we need to take into consideration payment information they currently use for manually deciding which Corridor payment will use and how much time will it take for payment to be delivered to the beneficiary.

Those payment parameters include:

  • Entity

  • Brand

  • Reason for Payment

  • Beneficiary Type (Individual/Corporate)

  • Beneficiary Account Country

  • Payment Ccy

Based on the above parameters, we can identify a Corridor (payment instrument + bank intermediary).

For each Corridor, we associate following data:

  • Payment Source Account Country

  • Cut off time

  • Days to complete payment

  • Intermediary countries

As we are taking into account more payment parameters to identify the correct source account country, cut off time, days to complete payment and potential intermediary countries, calculated execution date should be as accurate as possible.

Proposed Solution

We suggest to split current single field Corridor into two separate fields Payment Instrument and Intermediary Bank, to make Smart Date service compatible with future Payment Scheme Data Service that will be providing these two parameters as an output to input payment parameters.

Determining parameters

We know that some payment information can be retrieved from payments data within an uploaded multi payment file and the other need to be retrieved or derived from existing information. For each corridor parameter, we define how to retrieve it:

Entity - from client of the beneficiary provided in payment

Brand - same as Entity

Reason for Payment - From payment for new beneficiaries, from database for existing beneficiaries

The issue with this field is that it can hold any value. However, for Mass Payments it is important to differentiate between Salary and other reasons for payment. We can go with different approaches to identify Salary payment:

Recommended Approach

Use the Reason for Trade to determine the same Reason for Payment for all payments in that batch.

  • Pros: This is validated data and should avoid typo or issues with free text. It also aligns with current practice

  • Cons: There can be mixed payments in a trade (say for tax) which have to be separated manually

Alternative 1

Add validation for the Reason for Payment that it can hold only valid value from Reasons for Trade.

  • Pros: We are certain that payment is salary

  • Cons: we may introduce a significant amount of invalid payments as they may not contain valid reasons for payment. It would require education / communication to the end users.

Alternative 2

Match value provided in Reason for Payment against set of keywords that denotes salary, e.g. Salary, Payroll

  • Pros: We are not changing the existing validation process and thus not impacting the end user journey.

  • Cons: We can’t be sure we will not miss actual salary payments because of misspelling, abbreviation or similar reasons (e.g. Sal, Salary)

Beneficiary Type (Individual/Corporate) - From payment

Once we identify if the payment is Salary or not, we determine account type based on following rules:

  • If payment is Salary, Beneficiary is Individual

  • If payment is not Salary, Beneficiary is Corporate

Beneficiary Account Country

For new beneficiaries, we use Bank Account Country from payment

For existing beneficiaries, we use Beneficiary Account Country based on the Beneficiary Account Number provided in payment

Payment Currency - From payment

Adjusting Smart Date

Once we have identified parameters, we can pass them to Smart Date service to identify Payment Instrument and Bank Intermediary and to calculate the execution Date.

For Smart Date to accept and process new parameters we need to adjust:

  • Data models

  • Endpoints for manipulating the (configuration) data

  • Add a model for Corridor Rule (payment routing rule)

  • Add a new endpoint for retrieving payment route(s) based on Mass Payments Team's data model

  • Endpoint for calculating execution date

  • Procedure for calculating execution date

Adjusting Data model

Table below defines which information we need to store to be able to identify Payment Instrument and Bank Intermediary and to retrieve relevant information.

Parameter Name Purpose Example
Payment Instrument Description Swift
Bank Intermediary Description Barclays UK
Entity Search Criteria Mass Payment Entity
Brand Search Criteria Mass Payments Brand
Reason for Payment Search Criteria Salary
Beneficiary Type Search Criteria Individual
Beneficiary Account Country Search Criteria US
Payment Currency Search Criteria USD
Source Account Country Data to retrieve UK
Cut off time Data to retrieve 10:00
Days to complete payment Data to retrieve 1
Intermediary countries Data to retrieve

Note that Search Criteria parameters include Beneficiary Account Country, which may significantly increase the number of the combinations. Most probably we will have a single cut off and days to complete payment and some exceptions for specific combinations of countries and currencies. Therefore, we can have a “default” Payment Instrument and Bank Intermediary for e.g. ALL beneficiary countries (within other sets of parameters) and specific for certain beneficiary countries.

In the example above, we have defined a set of parameters specific to the US as a beneficiary country. In addition to that one, we can define a “default” one to target all other payments that have all parameters the same except for the beneficiary country, as shown in the table below.

Parameter Name Purpose Example
Payment Instrument Description Swift
Bank Intermediary Description Barclays UK
Entity Search Criteria Mass Payment Entity
Brand Search Criteria Mass Payments Brand
Reason for Payment Search Criteria Salary
Beneficiary Type Search Criteria Individual
Beneficiary Account Country Search Criteria ALL
Payment Currency Search Criteria USD
Source Account Country Data to retrieve UK
Cut off time Data to retrieve 10:00
Days to complete payment Data to retrieve 2
Intermediary countries Data to retrieve US

The same approach applies to Reason for Payment, where we can have default one for ALL reasons and specific ones for e.g. Salary.

We need to adjust existing Cutoffs model that stores parameters:

  • Corridor
  • Currency
  • Cutoff time
  • Days to complete
  • Intermediary Countries

to have:

  • Payment Instrument (splitting corridor)
  • Bank Intermediary (splitting corridor)
  • Source Account Country (new)
  • Beneficiary Account Country (new)
  • Currency
  • Cutoff time
  • Days to complete
  • Intermediary Countries

We also need to adjust existing Corridor model to store parameters we will use to identify Payment Instrument and Bank Intermediary. It currently has only:

  • Corridor

and it should be adjusted to have:

  • Payment Instrument (splitting corridor)
  • Bank Intermediary (splitting corridor)
  • Entity
  • Brand
  • Reason for Payment
  • Beneficiary Type
  • Beneficiary Account Country

Adjusting endpoints for manipulating the (configuration) data

We need to adjust existing endpoints for manipulating Cutoffs and Corridor data as defined above.

Adjusting endpoint for calculating execution date

We need to adjust existing endpoint for calculating execution date to accept Search Criteria parameters as defined above.

Adjusting procedure for calculating execution date

We need to adjust existing procedure for calculating execution date to take into account new Search Criteria parameters to be able to retrieve other data needed for calculation (Data to retrieve from above). We also need to adjust existing validation, etc.

Sample Calculation

Client uploads multi payment file with following payment information:

  • Currency: USD
  • Beneficiary Account Number: ESXXXXXXXXXXX
  • Reason for Trade: Salary/Payroll
  • Expected Delivery Date: some date
Step 1: Determining The Corridor

First, BOS calls Smart Date Service to determine the payment route(s) based on Mass Payments Team's data model.
This call can be replaced by a call to the Payment Scheme Data Service for all payments or for some of the payments depending on some conditions.

We start building a list of parameters for determining the corridor / payment route.

From the payment's properties, we can retrieve:

  • Currency: USD
  • Expected Delivery Date: some date

From Beneficiary Account Number, we can retrieve from database:

  • Beneficiary Account Country: ES

From the client, we can retrieve from the database:

  • Entity: Mass Payments Sample Entity
  • Brand: Mass Payments Sample Brand

Based on Reason of Trade, we can derive:

  • Reason for Payment: Salary/Payroll
  • Beneficiary Type: Individual

We pass the following list of parameters to the Smart Date endpoint for determining the corridor:

  • Entity: Mass Payments Sample Entity
  • Brand: Mass Payments Sample Brand
  • Reason for Payment: Salary/Payroll
  • Beneficiary Type: Individual
  • Beneficiary Account Country: ES
  • Payment Currency: USD

Smart Date Service returns an list of possible routes, ordered by weight / priority, where first route in te list has highest priority and should be taken as a first option.
According to Mass Payments Team's current data model, this might be a list with 1 or more elements, so the endpoint will return a list to be compliant with both the Payment Scheme Data Service and changes in Mass Payments Team's data model.

Step 2: Calculating The Execution Date

We pass the following list of parameters to the Smart Date endpoint for calculating execution date:

  • Beneficiary Account Country: ES
  • Payment Instrument (taken from the first element / route of the result from previous step)
  • Bank Intermediary (taken from the first element / route of the result from previous step)
  • Payment Currency: USD
  • Expected Delivery Date: some date

Smart Date retrieves following data from Corridor:

  • Payment Instrument: Swift
  • Bank Intermediary: Barclays UK

It also retrieves following data from Cuttofs:

  • Cut off time: 10:00
  • Days to complete: 2
  • Intermediary countries: US
  • Source Account Country: UK

It also retrieves information about holidays for involved countries: UK, ES, US.

Based on the holidays, cut off time and days to complete, it calculates execution date.

Alternatives

Alternative 1. Determining the Corridor during the calculation of the execution date in Smart Date Service

Determining the payment route / corridor in Smart Date Service as part of the process calculating the execution date.

Pros:

  • Only one external API call from BOS.

Cons:

  • Not compatible with the future Payment Scheme Data Service.
  • Mixing the concepts of calculating a date (which should remain in Smart Date Service for the long term) and choosing a route (which has only a temporary implementation in Smart Date Service).
  • Less flexible.

Whether to proceed with proposed solution or this alternative may depend on potential performance impact that we will be evaluating during implementation.

Alternative 2. Determining the Payment Instrument and Bank Intermediary in BOS

As an alternative, we could determine the Payment Instrument and Bank Intermediary in BOS and then provide those to Smart Date and not all other Search Criteria parameters. However, even in this case, we need to adjust the definition of Cutoffs model, because cutoff time, days to complete and intermediary countries depend on the Beneficiary Account Country, which is not taken into consideration. Corridor model needs adjustments as well, to include information about payment source country. Additionally, we should exclude source country to be passed as parameter to calculation endpoint, because it doesn’t make any sense to say payment will be released through Swift via Barclays UK and source country is China, which is currently possible to pass to the service.

Pros:

  • We do not introduce changes related to identifying the Payment Instrument and Bank Intermediary into Smart Date (not introducing tech debt), as we will remove it once new Payment Scheme Data Service is implemented

  • Logic to determine the Payment Instrument and Bank Intermediary remains with the service responsible for handling payments

Cons:

  • We are introducing more tech debt in legacy service, BOS, which is not recommended

  • We need to store additional configuration with rules how to determine Payment Instrument and Bank Intermediary

  • We need to define / implement a way of updating rules

  • In general, it is more difficult to implement changes in BOS compared to other newer services

Alternative 3. Create new Static Data Service

As another alternative, we could create a new Static Data Service that would be holding logic to determine Payment Instrument and Bank Intermediary based on the Search Criteria parameters. New service would be called from BOS to retrieve the Payment Instrument and Bank Intermediary, which would be later passed to Smart Date service to get Data to retrieve.

Pros:

  • Tech debt is not introduced in any of existing services, BOS or Smart Date.

  • Once Routing Rules Service is completed, we can “dismiss” new Static Data service and switch calling Routing Rules

Cons:

  • We need to implement additional service, which is basically subset of Routing Rules service, which is already being implemented

  • We need to support data adjustment, e.g. via API, in which case we need to implement endpoints etc. On the other hand, we already have CRUD endpoints in Smart Date. We could consider other options, but they may not be elegant as with API endpoints

  • We need additional infrastructure

Operations

Introduced changes will not have an impact on existing operations.

Security Impact

N/A

Performance Impact

Depending on the solution we proceed with, if we decide to have two calls to Smart Date, more time will be required to parse multi payment file. Otherwise, we do not expect additional impact on the service performance, although we are adding more configuration data to the Smart Date service database.

Data Consumer Impact

Depending on the agreed way of identifying Salary payments, should we introduce validation for Reason for Payments, it may increase the number of invalid payments. To avoid that situation, an appropriate communication should be made in advance to Mass Payments users.