Payments

Faster Payments (FPS)

• Faster Payments (FPS) are GBP to GBP electronic payments that can be made from one FPS enabled account to another. These are offered on GBP programs.
• Payments will typically arrive almost immediately (with a maximum delay of up to two hours).
• Individual payments of up to £1 million can be made using FPS. Additional limits can however be set depending on the type of account(s) in your program.

SEPA Credit Transfers

• SEPA (Single Euro Payments Area) is a payment integration initiative of the European Union, permitting bank transfers denominated in euros to be sent across the SEPA region as though it were a single domestic market. SEPA transfers must originate and settle in countries within the SEPA region.
• SEPA payments are offered on EUR programs.
• Solaris can provide partners and their users with their own International Bank Account Number (IBAN) which, along with Solaris' SEPA compliant Bank Identifier Code (UFPOLT21XXX), can be used to send and receive SEPA payments.

Payments integration at a glance

Adding a beneficiary (recipient)

Before a transfer can be made, a beneficiary (recipient) to receive the transfer must first be added. Recipients are added via the Transfer/AddRecipient method. When calling this method, remember to include:

• The recipient's name via BankAccountHolderName .
• The correct BankAccountTypeID (UK or SEPA) of the recipient, as well as:
  • The AccountNumber and SortCode for recipients in the UK (GBP payments).
  • The IBAN and BIC for recipients in the SEPA area (EUR payments).

The response will include a RecipientBankReferenceID value which should be persisted, as it will be required when making a transfer to a recipient (see below).

Making a transfer

Once a recipient has been added, transfers can be made using the Transfer/BankTransfer method, which must include the following:

• The RecipientBankReferenceID of the recipient.
• The TransferTypeID to denote the type of payment, as well as:
  • The AccountNumber and SortCode for payees in the UK (GBP payments).
  • The IBAN and BIC for payees in the SEPA area (EUR payments).

Closed Loop Payments

Closed Loop Payments (CLP) provide the facility for partners to restrict the external accounts through which funds can be loaded onto, and unloaded from, your customer accounts. This is achieved by requiring users to specify "nominated" account(s) and limiting inbound and outbound payments to these accounts exclusively.

• Closed Loop Payments are enabled by Solaris at program level. Once enabled, they apply to all user accounts on your program.
• The maximum number of accounts a user can nominate is configurable. This limit applies similarly to all accounts on your program.
• Closed Loop Payments currently apply only to Faster Payments and SEPA credit transfers.
• User nominated accounts must be part of the domestic payments scheme provided in your program. For example, when implementing Closed Loop Payments for UK users, all nominated accounts must be able to send and receive Faster Payments. Similarly in the EEA, nominated accounts must be able to send/receive SEPA Credit transfers.

When Closed Loop Payments are enabled on your program, the following payment restrictions and checks will be applied:

• Payments can be made to and received by a user via their nominated accounts only:
  • Outbound payments cannot be made from a user's account to non-nominated accounts.
  • Inbound payments to a user's account are checked to ensure they are from a nominated account. If not, the payment will be automatically returned to the sender.
• For existing users, their current bank details will be converted into (and will constitute) one of their permitted nominated accounts.

Managing nominated accounts

Once Closed Loop Payments have been enabled and configured for your program, you can manage user-nominated accounts as below:

• To nominate an account, use the Transfer/AddRecipient method. Please note: If the user has already nominated the maximum number of accounts permitted, this request will fail with the error code 6531 . A successful request will provide a RecipientBankReferenceId , which should be persisted for future reference.
• To remove a nominated account, use the Transfer/DeleteRecipient method, supplying the respective RecipientBankReferenceID .
• If changes are required to an existing nominated account, the account must first be removed (via Transfer/DeleteRecipient) and then re-added using the Transfer/AddRecipient method.

Confirmation of Payee

Confirmation of Payee at a glance

Confirmation of Payee (CoP) enables users (senders) to verify the identity of a recipient (the payee) before the recipient is added and the respective payment made. This provides an additional check to better ensure the payment is going to the intended recipient. At a very high level, the CoP workflow is as follows:

1. The user enters the recipient details - sort code, account number, account type and expected account owner name into your application.
2. Your application calls the Solaris API, which checks these details against a directory, with the response indicating one of the following match types:
   • Positive match - the supplied details match exactly.
   • Partial (close) match - the name provided is a close match to that on the account.
   • Negative match - the name does not match that on the account.
3. Depending on the match type received, your application directs the user through the appropriate workflow , permitting them to undertake the relevant (match dependent) actions, which may include:
   • Proceeding with adding the recipient and making the payment.
   • Cancelling the payment.
   • Amending the account details and re-trying the check.

Detailed information on all of these steps including API request and response, relevant workflows, user actions and appropriate messaging to display is outlined below.

Verifying recipients via the API

To verify the recipient details provided by the sender, call the Transfer/VerifyPayee method, passing:

• The AccountNumber , SortCode and AccountOwnerName of the account to verify, as well as the LegalOwnerType (either "Personal" or "Business").
• The ConsumerID of the user on behalf of whom the request is being made.

An example request is shown below:

{
    "ConsumerID": 227308,
    "AccountNumber": "00156880",
    "SortCode": "603878",
    "AccountOwnerName": "Jane Smith",
    "LegalOwnerType": "Personal"
}

Recipient verification API responses

The method response will contain the following parameters, the values of which denote the nature of the match:

• Matched - denotes whether the provided details match exactly. Will be true for a positive match and false for either a partial (close) match, or negative match.
• Reason denotes the reason for a partial or negative match (refer to the table below ). Always null for a positive match.
• ReasonCode specifies the specific reason code for a partial or negative match (refer to the table below ). Always null for a positive match.
• Name denotes the correct name of the account owner, and will only be returned in cases of a partial (close) match.

Examples of the match types are outlined below:

Positive match response

A positive match, where the details provided match those of the account exactly, is denoted by a Matched value of true:

{
    "Matched": true,
    "Name": null,
    "Reason": null,
    "MatchedBank": "FICTITIOUS BANK LIMITED",
    "ReasonCode": null,
    "ResponseWithinSla": true,
    "LegalOwnerType": "Personal",
    "ResponderRegistrationId": "100117",
    "Description": "Success",
    "ResponseCode": "000",
    "ResponseDateTime": "2024-01-30T13:36:34.342",
    "ClientRequestReference": "",
    "RequestID": 638422185943426515
}

Partial (close) match response

A partial (close) match, where the account owner name provided closely matches that of the account, is denoted by the presence of a populated Name parameter, which details the correct name of the account owner.

{
    "Matched": false,
    "Name": "Jane Smith",
    "Reason": "There may be a match on the Account name",
    "MatchedBank": "FICTITIOUS BANK LIMITED",
    "ReasonCode": "MBAM",
    "ResponseWithinSla": true,
    "LegalOwnerType": "Personal",
    "ResponderRegistrationId": "100117",
    "Description": "Success",
    "ResponseCode": "000",
    "ResponseDateTime": "2024-02-01T13:00:56.074",
    "ClientRequestReference": "",
    "RequestID": 638423892560746432
}

Negative match response

A negative match indicates the account owner name provided does not match that of the account. This is denoted by a Matched value of false and Name parameter value of null.

{
    "Matched": false,
    "Name": null,
    "Reason": "Account Name does Not Match",
    "MatchedBank": "FICTITIOUS BANK LIMITED",
    "ReasonCode": "ANNM",
    "ResponseWithinSla": true,
    "LegalOwnerType": "Personal",
    "ResponderRegistrationId": "100117",
    "Description": "Success",
    "ResponseCode": "000",
    "ResponseDateTime": "2024-01-30T13:37:22.721",
    "ClientRequestReference": "",
    "RequestID": 638422186427214187
}

Handling the verification response

Each response type (positive match, partial (close) match and negative match) need to be handled with a specific flow.

• Positive matches, where the Matched parameter is true , must be handled via the Positive match flow .
• Partial (close) matches, where the Name parameter is populated, must be handled with the Partial match flow .
• All non-positive matches will contain a ReasonCode and/or Reason parameter. A full breakdown of these, along with the respective flow to handle the reason is available in the table below.

Response Reason Codes

Confirmation of Payee Workflows

The key CoP workflows, including messaging and API calls are outlined below. This flow combines a number of actions in a single, user friendly journey:

1. Verifying the recipient details.
2. Creating and adding the recipient (for positive matches or if the user dismisses the advisory messages presented).
3. Initiating the payment or transfer to the recipient.

Please note the below illustrates an outline only - your flows may include or require additional dialogs, confirmation screens etc.

Presenting match results to users

• Clear and appropriate advisory messaging must be provided to the user to indicate the nature of the CoP check match, and the paths/actions available to them.
• In all instances, make the messaging wording clear and concise, using simple and easy to understand language. It is advised that you avoid using:
  • technical terminology or banking "jargon". For example, avoid terms such as "verify", "payee", "payer", "authorise" etc.
  • the use of T&Cs or any language regarding liability.
• The exact wording of the user facing messages is at your discretion, Solaris will however need to view and verify the messages on all paths/flows.
• For the various match outcomes below, example advisory messages are shown - their formatting, styling and content is for demonstration purposes only.

Positive match flow

• The supplied account name is considered to be a match.
• The user can now proceed to make the payment, or cancel the payment.

Example user facing message:

success

The account name is a match.

Partial (close) match flow

• The account owner name supplied does not match that of the account, it is however a close match.
• The correct account name will be provided to you via the Name parameter in the verification API response , and should be included in the message shown to the user.
• At this stage the user must be able to:
  • Select the correct account name and proceed with the payment
  • Amend account details and perform another CoP check.
  • Cancel the payment.
  • Proceed with the payment using the supplied account details (including incorrect but closely matched name). If the user opts to proceed, they must actively dismiss the warning message. The second warning message must then be presented to the user.

Example user facing message: (replace "..." with the correct account name returned in the response)

Its a close match

The name you gave us is not the same as the name held on the Account. It's a close match, the name is ...

Negative match flow

• This flow covers scenarios where the account details supplied returns a negative match, and/or other issue(s) have prevented a successful attempt to validate the account details.
• At this stage the user must be able to:
  • Amend the account details and perform another CoP check.
  • Cancel the payment.
  • Proceed with the payment. If the user opts to proceed, they must actively dismiss the warning message. The second warning message must then be presented to the user.

Example user facing message:

No Match

The name you gave us is not the same as the name held on the Account.

Account does not exist flow

• The account for the details supplied does not exist. Messaging to the user must make it clear the account does not exist, the user cannot continue with the payment and should check the account details with the recipient.
• At this stage the user must be able to:
  • Cancel the payment.
  • Amend account details and perform another CoP check.

Example user facing message:

Account not found

The account details supplied do not exist. Please check details with recipient

Second Warning Message

In cases where it is not possible to verify the recipient account details, or there is no positive match for the details, the user should first be shown an initial advisory message detailing this. Users may still however opt to proceed with the payment by dismissing this message. On dismissing the initial message, you must provide a secondary warning message indicating that the funds may not be able to be recovered should the user proceed with the payment.

Example user facing message:

Do you wish to proceed?

Initiating this payment may lead to funds being sent to the wrong account and it may not be possible to recover the money.