Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
In this guide we propose an ideal flow, which is designed to optimize the user experience. However, the Source PSP has the freedom and flexibility to call the APIs in a different sequence or to use only certain elements of the functionality provided through Nexus.
For the examples in this guide, Maria Rossi, who lives in Italy, wants to send SGD 150 to Wei Long who lives in Singapore.
For simplicity of the example, the exchange rate is 1.5000 (so EUR 1.00 = SGD 1.50).
This example is for a person-to-person (P2P) flow. However, a similar flow would be used for business-to-business (B2B) and business-to-person (and vice versa) payments (subject to any transaction size limits imposed by the instant payment systems).
The mobile app screens shown give an example of how a bank or PSP may implement Nexus into their existing app or online banking channels. They are mock-ups only – not a functional app. There is no dedicated Nexus app.
The general flow is summarised in the diagram below:
Once the Sender has entered either Source Currency Amount or Destination Currency Amount, the PSP should use the GET /quotes/
API operation to retrieve quotes (see FX Service APIs for more detail).
In the case that the PSP is also an FXP, they should still use this quote to retrieve current rates, as Nexus will generate a quote ID specific to this payment which must be referenced in the pacs.008 payment instruction. Without this quote ID, the exchange rate cannot be validated and the payment will fail.
Nexus will retrieve rates for the currency and country pair selected
For each rate, Nexus will:
automatically apply any improvements offered by that FXP based on size of the transaction or the PSP requesting the rate. (See Tier-based improvements and PSP-based improvements for more detail.)
check that the Source Currency Amount and Destination Currency Amount (at the given rate) do not exceed the MaxAmt
values in either the Source or Destination IPS, and adjust those values if they do.
calculate the amounts, in Source and Destination Currency, that can be sent at this rate. These are defined in the following fields in the response to GET /quotes/
:
AdjustedSourceAmount
AdjustedDestinationAmount
Where the Source Currency Amount or Destination Currency Amount provided by the Sender exceeds the MaxAmt
of the respective IPS, Nexus will apply whichever cap is the smaller at the current rate. This means the AdjustedSourceAmount
and AdjustedDestinationAmount
will never exceed the maximum that can be sent through the relevant IPS.
Nexus will then return the full list of adjusted and improved rates, with Quote Ids that are unique to this GET /quotes/
request. The Quote Id must be referenced when the PSP submits the pacs.008 payment instruction (or the domestic equivalent).
The GET /quotes/
API must be called again every time the Sender changes either the Source Currency Amount or Destination Currency Amount, since changes in the transaction value may (a) breach the maximum transaction value or (b) qualify for different size-based improvements to the rate.)
The PSP selects the quote that the PSP wishes to use (from any FXP with which is has already onboarded). This could be the best quote available or a quote from a preferred FX Provider.
The PSP does not show the list of quotes to the Sender.
In the case that the PSP also acts as an FX Provider, the PSP can select its own quote. Please note that when the PSP selects itself as FX Provider, the PSP need to have quotes registered as an FX Provider in Nexus. See PSPs who are also FXPs.)
Complications can arise when there are two or more IPSs in the Destination Country, and some quotes are only valid for one of those IPSs. See Selecting quotes when there are multiple IPSs in one country for details.
The PSP can also add a markup to the FX rate before it is shown to the Sender. PSPs may wish to mark up the FX rate they are provided by the FX Provider instead of (or in addition to) charging a transaction fee.
When the PSP applies a markup to the FX rate, the pacs.008 message should use the following elements in a specific way:
Instructed Amount = the amount deducted from the Sender’s account
Exchange rate = 1.5000 (the exchange rate agreed between the Source PSP and the FX Provider, as defined in the Source PSP’s preferred quote provided by Nexus
Interbank Settlement Amount = the amount the Source PSP actually transfers to the FXP’s Settlement Account Provider (rather than the amount deducted from the Sender’s account, which will be higher to account for the FX markup)
Now the exchange rate and Source Currency Amount and Destination Currency Amount can be shown to the Sender:
If the Source PSP does not plan to mark up the FX rate offered to the Sender, it can simply use the AdjustedSourceAmount
and AdjustedDestinationAmount
fields in the quote response to update the Source Currency Amount and Destination Currency Amount fields in the app.
If the Source PSP plans to mark up the FX rate offered to the Sender, it should calculate the Effective Rate (ie. Preferred rate from Nexus * PSP’s Markup = Effective rate)
If the Sender defined the Source Currency Amount, the AdjustedSourceAmount
should be multiplied by the (Effective) Rate to get the Destination Currency Amount
If the Sender defined the Destination Currency Amount, the AdjustedDestinationAmount
should be divided by the (Effective) Rate to get the Source Currency Amount
The Source PSP should confirm whether the amount originally requested by the Sender has been capped (because it exceeds the maximum amount in either the Source IPS or Destination IPS):
If the Sender defined the Source Currency Amount, AND this amount is greater than the AdjustedSourceAmount
, the Source PSP should add a notice to the Sender that the amounts have been adjusted to the maximum value that can be sent.
If the Sender defined the Destination Currency Amount AND this amount is greater than the AdjustedDestinationAmount
, the Source PSP should add a notice to the Sender that the amounts have been adjusted to the maximum value that can be sent.
The effective exchange rate applied (after any markup added by the PSP) should also be shown to the Sender
Now that the Sender has approved the payment, the PSP must set up the Nexus-standard pacs.008 payment instruction which will be submitted to the local IPS.
The PSP uses the GET /intermediaryagents/
API operation to retrieve the Intermediary Agents, based on the ID of their preferred quote. This information is used in the pacs.008 message to specify the accounts held by the FX Provider in both the Source and Destination country. Funds will be paid into the FXP's account in the Source Country and paid out of their account in the Destination Country.
The PSP constructs the pacs.008 payment instruction: this will make use of information from the earlier responses to the following APIs:
GET /quotes/
GET /creditors/
GET /intermediaryagents/
The Source PSP should define whether the payment is time-critical or non-time critical, by setting the Instruction Priority (/Document/FIToFICstmrCdtTrf/CdtTrfTxInf/PmtTpInf/InstrPrty/
) as follows:
NORM
: default, for all payments that are not urgent or time-critical. This flag will allow the Destination PSP extra time (to be defined in the Nexus scheme rulebook) to complete sanctions screening in the event the payment triggers an alert.
HIGH
: for urgent payments and physical point-of-sale payments (where the customer cannot leave the store until the payment is confirmed). If HIGH
is used, the Destination PSP will reject any payments that it cannot immediately accept. Payments marked HIGH
are more likely to be rejected if the Destination PSP does not have real-time sanctions screening systems. They will also be rejected if the payment generates a sanctions alert which the Destination PSP cannot resolve without manual intervention. This means that HIGH
should not be used unnecessarily.
See Nexus pacs.008 for further details.
Once the Sender has confirmed the payment, the PSP should submit the pacs.008 payment instruction to the Source IPS (using the same secure connection that the PSP normally use to submit domestic payment instructions to the IPS). ]
Nexus will coordinate the payment between the Source and Destination Countries.
Checking for duplicated or fraudulent payments
In general, Nexus trusts the Source PSP and assumes that any payment instructions received from the Source PSP are legitimate and should be processed. It is therefore the responsibility of the Source PSP to defend against sending fraudulent payments or payments that were sent in error.
Nexus uses the UETR (Unique End-to-End Transaction Reference) to check whether a payment is unique. Nexus will check whether a payment with the same UETR has already been processed, and will not process duplicates.
However, Nexus will not check whether similar payments with different UETRs are possible duplicates. For example, if a Source PSP sends two payments, for the exact same amount, between the same sender and recipient accounts, but with different UETRs, Nexus will assume both payments are intentional and will process both.
Nexus does not currently have any fraud prevention tools or transaction monitoring, although this could be added to the roadmap in due course.
The proof of concept uses End2EndId as the unique identifier, but a production version will need to use UETR. This is because we cannot be sure that the End2EndId for a specific payment will be universally unique across all PSPs and all IPSs in Nexus, whereas UETR is by definition universally unique (as it is generated as a Universally Unique Identifier – UUID.)
If the Source PSP supports the Request for Information (RFI) service, the Source PSP should be prepared to respond to any RFIs relating to this payment. These requests could come from either of the Settlement Account Providers or the Destination PSP. (See Request for Information for further details.)
All cross-border payments through Nexus will need to be screened by the PSPs involved in a payment against the sanctions lists that apply in their jurisdiction (‘sanctions screening’). In most cases, sanctions screening software used by the PSP will first compare the name of the Sender or Recipient and look for similar names on the sanctions lists. If a positive ‘hit’ is found, the software can use additional data, such as address, date and place of birth, or national identity number, to confirm whether the Sender or Recipient is actually the person on the sanctions list or just a similar name (a “false positive”).
FATF’s Recommendation 16 requires the following information to be included in cross-border payments:
For the Sender:
The name of account holder (Mandatory)
The account number
AT LEAST ONE OF THE FOLLOWING:
Address
Place and date of birth
National ID number or another unique customer identification number
For the Recipient:
Recipient (Beneficiary) Account Number
Recipient (Beneficiary) name
Additional requirements may apply in each jurisdiction. For example, a particular country might define the Creditor > Postal Address element to be mandatory.
Each IPS can define this required information in Nexus, through the Reference Data Service, so that it can be shared with PSPs.
The PSP should therefore ensure that all (pacs.008
) payment instructions to Nexus include the Recipient’s name as a minimum. Failure to include this basic information will result in the payment failing the sanctions screening of PSPs and involved in the payment. Adding further information in addition to the name will reduce the likelihood of the payment triggered a false positive hit and being delayed.
The PSP should now review the Creditors
response to confirm whether:
Name is present (Nickname is not sufficient for sanctions screening)
At least one of the other data points specified in FAFT Recommendation 16 (see above) is present
If the Name
element is blank, the PSP must display a form asking the Sender for the Recipient’s full name. (The Recipient’s name is required as a minimum, in line with FATF Recommendation 16.)
The PSP can display fields for them to enter the Recipient’s address. The PSP should check the information it received from GET /countries/{country_code}/upss
to establish if these additional fields are mandatory in the Destination IPS.
Although the PSP could also ask for Date and Place of Birth and National Identity number, Recipients may be uncomfortable with sharing this information directly with the Sender. (In contrast, when the Destination PSP shares the information in response to an RFI request, the information is shared securely through Nexus and not shown to the Sender, except for the Name).
Before the PSP send the payment instruction the Source PSP will need to screen the Recipient against the sanctions lists applicable in the PSP’s jurisdiction. (It is assumed that the Sender will already have been screened by the Source PSP as part of the PSP’s regular KYC, AML and screening processes.)
(This step can be done later if the PSP's screening software requires a complete pacs.008
payment instruction.)
If the Destination PSP supports RFI, Nexus will already have issued an RFI to the Destination PSP during the POST /creditorrequests/
API process. So there is no need for the Source PSP to issue a further RFI to the Destination PSP at this point.
The PSP should now ask the Sender to review all details before confirming the payment.
The Nexus scheme has specific requirements on the minimum information that should be shown to the Sender, to ensure transparency around the costs and FX rates that will be applied to the payment. The PSP should display:
The Source Currency Amount – the amount that will be deducted from the Sender’s account
The Destination Currency Amount – the exact amount that will be credited to the Recipient’s amount
The exchange rate that will be applied – this is the effective exchange rate paid by the Sender, after any markup applied by the Source PSP, rather than the exchange rate paid by the Source PSP to the FXP. (See Step 5 - Marking up FX rates.)
The fees that the Sender will be charged by the Source PSP. As per the Nexus rulebook, these must be charged to the Sender as a separate line item rather than as a deduction from the amount transferred.
The PSP can also offer the Sender a field to add a message/reference to the payment, which will be visible to the recipient. This message can be stored in the /Document/FIToFICstmrCdtTrf/CdtTrfTxInf/RmtInf/Strd/CdtrRefInf/Ref
element of the pacs.008. (The message field can alternatively be added at any other point in the flow.)
Using data retrieved from the GET /countries/
API operation, the PSP can display a dropdown Countries list to the Sender via the PSP’s app or other channel. (Left and middle figure below.)
The response to GET /countries/
lists all Nexus-enabled countries and the currencies available in that country. If the Sender selects a country with more than one currency, the PSP should immediately:
Display a second form element (eg <select>
or <radio>
) that lists the currencies available (Right hand screen below.)
Ask the Sender to select the currency that the Recipient expects to receive
The app should store the select country (and currency, if applicable) in memory, as it will be required when retrieving FX quotes
On the next screen, the PSP should now generate a form that will allow the user to define either:
The amount the Sender wishes to send (the Source Currency Amount), OR
The amount the Sender wishes the Recipient to receive (the Destination Currency Amount)
Different IPSs have different limits on the maximum value of a transaction. The GET /quotes/
API operation in Nexus will automatically apply these limits and reduce the Source Currency Amount or Destination Currency Amount accordingly. However, the PSP can also use client-side validation (eg setting the max
attribute of the HTML form input element) to cap the amounts that can be inputted:
The Source Currency Amount field (labelled “You send” in the example screen) can be capped to either:
the maximum value that the PSP is willing to send, or
the maximum value of the IPS to which the PSP is connected to. (This should be known by the Source PSP; it could alternatively be retrieved by calling GET /ipss/{country_code}
with the country code of the PSP’s home country.)
The Destination Currency Amount field (labelled “They receive” in the example screen) should be capped to the maximum defined in the /IPSs/IPS/MaxAmt
element that is returned in response to GET /ipss/{country_code}
with the country code of the Destination Country.
Where the IPSs element contains two or more Destination IPSs with different MaxAmt values, use the larger amount as the max
attribute on the form input element. Nexus will automatically calculate the maximum amount that can be sent for each specific quote depending on which IPS the FXP is a member of.
Next the PSP should provide the Sender with a form that allows them to select from the addressing formats available in the Destination Country and enter the proxy or PSP account details.
The form should first list the proxy formats, since these are usually easier for the Sender to input, followed by IBAN, followed by any domestic account formats.
See API - Proxy Service for instructions on generating this form dynamically using the GET /countries/{country_code}/proxyschemes/
. This API operation will return the list of proxy formats available in the destination country; this data can be used by the app to dynamically generate the form.
If the Destination IPS accepts IBAN or local account details, these can also be used through Nexus.
The PSP should check the whether the IBAN is accepted. This is defined in the IPSs/IPS/IBANAccptdInd
element. If IBAN is accepted (IBANAccptdInd = true
), this should be displayed in the addressing options field after the various proxy formats.
The PSP should also check whether a local account format is accepted, alongside a PSP identifier (such as BIC). This is defined in the /IPSs/IPS/LclAcctId/LclAcctIdAccptdInd
element of the response to GET /countries/{country_code}/ipss
. This option should be displayed last.
The PSP should ask the Sender to select either (a) a proxy (eg. phone number) or (b) a PSP identifier (eg BIC) and account details, depending on what information the Recipient has given them.
On the next screen (right pane in the diagram above), the Sender should be asked to enter the specific addressing details, depending on the option they selected before. (See API - Proxy Service for instructions to generate this form dynamically.)
The PSP should now send either the proxy or account details provided by the Sender to the GET /creditors/
API operation. This triggers the following steps:
If a proxy is provided, Nexus will send the proxy to the proxy lookup service in the Destination Country. (The proxy lookup service will map the proxy to a PSP identifier (eg BIC) and account number, or return an error if the proxy is not registered.)
Using the PSP identifier (provided by the proxy lookup service or by the Sender), Nexus will check that the Destination PSP is enabled to receive Nexus payments and able to apply sanctions screening to incoming payments (ie “Nexus reachable”). If not, Nexus will return an error (“Destination PSP not reachable”).
Nexus will check whether the Destination PSP supports the Request For Information process. If so, it will contact the Destination PSP via the RFI
API (or a camt.026 message) to request verified information about the Recipient, such as the name and address, so that the PSP doesn’t need to ask the Sender for this information. (See Request for Information)
Nexus will respond to the PSP with:
the PSP identifier
the account number
a list of the IPSs in which the PSP is reachable
the Recipient’s name or nickname (as provided by the proxy service or the response to the RFI)
any further personal data on the Recipient that Nexus is able to retrieve from the Destination PSP via the RFI.
The PSP should now ask the Sender to confirm that they recognize the Recipient’s name or nickname before proceeding with the payment. The confirmation of payee step allows the Sender to verify that the holder of the Destination Account is actually the person or business they intend to pay. This provides a check against fraud as well as giving the Sender greater confidence that they entered the proxy or account details correctly.
In most cases, the response to the Creditors response will include either the Recipient’s real name or a nickname defined by the Recipient. This information is retrieved from either:
the proxy lookup service in the Destination Country, or
the Request for Information sent directly to the Destination PSP
The PSP should show this to the Sender and ask them to confirm that this is the name they are expecting to see.
In some cases, the nickname and real name fields will both be blank. This can occur when:
The Destination PSP does not support RFI, AND either:
The proxy lookup service itself does not store or provide the account holder’s name or nickname OR
The Sender provided a local account number (so there was no proxy lookup)
In this situation, there is no way for the Sender to confirm the identity of the Recipient and this confirmation-of-payee step can be skipped. In such cases, the Sender must send the payment “blind” to the real identity of the account holder. This may increase the risk of them making a payment to a fraudulent or mistaken account.
This is one reason why it is alway preferable to list the proxy options first in the addressing form, rather than IBAN or a local account number. (Most proxy schemes will return a name or nickname but it is possible that many banks will not support the RFI process.)
When the Destination PSP accepts the pacs.008, they will respond with a pacs.002, which will be sent back to Nexus. Nexus will forward the pacs.002 to the Source IPS, who will forward it to the Source PSP.
For pacs.008s with an instruction priority of HIGH, the pacs.002 will have one of the following status codes (found in /Document/FIToFIPmtStsRpt/TxInfAndSts/TxSts/
):
ACCC
: the Destination PSP has accepted the payment and credited the Recipient’s account
The Source PSP should inform the Sender that the payment has successfully reached the Recipient
RJCT
: the Destination PSP payment has been rejected. A reason code may provide further information. In the Source IPS, any reservation of funds against the Source PSP has been cancelled and any movement of funds from the Source PSP to the Source Settlement Account Provider has been reversed.
The Source PSP should inform the Sender that the payment could not be made.
For pacs.008s with an instruction priority of NORM, two addition status codes are possible (in addition to ACCC and RJCT):
ACWP
: The funds have reached the Destination PSP, but have not yet been credited to the Recipient’s account. This may be because the payment triggered a sanctions screening alert which needs to be manually reviewed.
When ACWP
is received, the Source PSP must inform the Sender that the payment is still being processed but has not yet been credited to the Recipient. The Source PSP should ensure the Sender knows how to confirm if/when the payment has been completed (eg via a notification from the app, or by checking their statement)
An ACWP
response will be followed up later with one of the following outcomes. The follow-up response must be set within the SLA time defined in the Nexus Rulebook (currently proposed to be 2 hours):
A pacs.002 with the status ACCC
, meaning that the Recipient’s account has been credited.
A pacs.002 with the transaction status BLCK
, meaning that the funds will not be returned to the Sender and have not been credited to the Recipient. This is most likely in the case that the payment was identified to be illicit after sanctions screening.
A pacs.002 with the transaction status RJCT
meaning that the Destination PSP has been unable to ascertain whether the payment can be accepted or not. This may mean that the Destination PSP was unable to manually review a sanctions screening alert within the time limit defined in the Nexus Scheme Rulebook.
This will be followed by a pacs.004 message returning the funds.
The Source PSP should inform the Sender that the payment has been unsuccessful and that the funds will be returned to the Sender’s account.
When the ACCC message is received, the Sender should be notified (possibly through a notification or update on the app/online banking, or via an update to their statement).