Role and responsibilities of the Instant Payment System Operator (IPSO)
Eligibility to be an IPSO in Nexus
Eligibility requirements for Nexus are defined in detail in the Nexus Scheme Rulebook, but at a high level:
An IPSO must be able to process individual payments between accounts within the timeframe defined in the Nexus Scheme.
An IPSO must ensure the settlement certainty requirements as defined in the Nexus Scheme Rulebook are adhered to and do not lead to negative consequences for end-users.
The IPSO must meet the other obligations and requirements defined in the Nexus Scheme Rulebook.
Joining the Nexus Scheme as an IPSO
An IPSO must sign an adherence agreement to become a direct member of the Nexus Scheme. The adherence agreement requires them to comply with the various obligations and responsibilities of being an IPSO in Nexus, as defined in the Nexus Scheme rulebook.
Onboarding with Nexus
An IPSO joining Nexus must meet the obligations in the Nexus Scheme Rulebook, and:
Make the necessary changes to their IPS to be compatible with Nexus. This can be the domestic IPS and/or the cross-border implementation, where applicable. This is a design choice for the IPSO.
Lead an industry engagement to ensure that PSPs make the changes to become compatible with Nexus.
Set up connectivity to Nexus
Update the Nexus Service Desk with the necessary reference data.
The IPSO must ensure that this information is kept up to date.
Register its member PSPs with Nexus (via the Nexus Service Desk). The IPSO should register all of its member PSPs, including those not participating in Nexus. This allows Sending PSPs to validate the validity of a PSP. If that particular PSP is not reachable via Nexus, the Sending PSP may still be able to make the payment using another non-Nexus payment channel. An exception will be made in the case the IPSO is legally not permitted to share the data on its member PSPs. (Note that this data is typically already shared via other sources, such as the BIC directory provided by SWIFT.)
Onboarding of PSPs
Nexus maintains a register of all PSPs that are members of Nexus-connected IPSs, whether or not those PSPs are able to send and receive Nexus payments.
PSPs do not directly onboard with Nexus; instead they onboard via the IPSO. Upon onboarding with Nexus, a new PSP must provide its IPS with reference data, which the IPS must make available to Nexus, including:
the name of the PSP
the financial institution identifiers used by the PSP eg BIC, LEI and any Clearing System Member Identifiers.
the Instant Payment System the PSP is a member of (ie in which payment systems can the PSP receive payments). If a PSP is a member of multiple IPSs, each IPS must provide the reference data to Nexus.
The capabilities of the PSP (in relation to the IPS)
Support for time-critical and/or non-time-critical payments
Support for
acmt.023andacmt.024Support for
pacs.028(for future use)Support for
pacs.004(for future use)Support for
camt.056(for future use)
the go-live date from which the PSP is able to receive Nexus payments for the relevant IPS
the address information (email address, phone number) for operational matters, including inquiries, complaints, disputes and requests for recall
The IPSO must ensure that the reference data is kept up to date.
Nexus will make this information available to other participants through the GET /countries/{countryCode}/psps API operation.
Offboarding a PSP
Upon termination (for whatever reason) of one of the PSPs as a member of Nexus or a member of the IPS, the data in the Nexus reference data must be updated by the IPSO as soon as possible.
Nexus will make this information available to other participants through the GET /countries/{countryCode}/psps API.
Timing
The IPSO will need to adhere to the timing as specified in the Nexus Scheme Rulebook.
Each IPS adhering to Nexus Scheme is expected to operate with a defined Maximum Execution Time, which is set and may evolve from time to time, by its own governance mechanism. The IPSO will also need to ensure that its Participants adhere to the timing requirements resulting from the obligations of the IPSO.
The Scheme governance determines and publishes the Maximum Execution Time for Nexus Gateways.
The Scheme will not set a Maximum Execution Time for an end-to-end Nexus Payment. The actual end-to-end execution time is derived by adding the MET’s of the Source IPS, Nexus and the Destination IPS together. The resulting MET is considered as a “best effort” – not a guarantee; it will rely on the performance of local IPSs.
Rejects
Nexus will not impose limits on the number of rejects resulting from payments in a specific corridor.
It is the responsibility of the IPSOs to signal anomalies or issues resulting in an unusual high percentage of rejects and take corrective actions. However, the Nexus Scheme Organisation may monitor the level of rejects and raise concerns with IPSOs where a reject rate leads to a worse user experience or signals issues with scheme adherence.
Availability Requirements
The IPSO should have the ability to process Nexus Payment requests, with the required availability (in principle 24/7/365), and with business continuity arrangements.
The IPSO should maintain availability of at least 99.9% (no more than 43 minutes of downtime per month).
Compliance
The IPSO must have signed the adherence agreement with the Nexus Scheme Organization prior to processing Nexus Payments.
The IPSO must manage the onboarding of PSPs and SAPs to Nexus.
The IPSO must have an addendum to its local Scheme Rulebook and/or a separate -cross-border agreement, stipulating the Nexus requirements that apply to its participants.
The IPSO must ensure that the onboarded participants have signed the addendum or separate cross-border agreement before the PSP or SAP starts to process Nexus payments.
Last updated