This Blueprint

This blueprint explains the basic concepts of SEPA, and the capabilities needed for a payment service provider (PSP) to implement SEPA Instant Credit Transfers.

EACHA has developed and published common guidelines for clearing and settlement of SEPA Payments. This blueprint makes extensive use of EACHA materials to explain clearing and settlement of SEPA credit transfers.

Single Euro Payments Area (SEPA)

SEPA is an initiative to allow cashless euro payments, using credit transfer and direct debit, to any participating country just like domestic payments. The initiative is led by the European banking and payments industry with support from national governments, the European Commission, the Euro system, and other public authorities.

At the time or writing (October 2023), there are 36 participating countries (SEPA area), including the United Kingdom and others that do not use the Euro or are not European Union participants. Broad participation is critical to eliminate differences between national and cross-border payments and harmonise cashless euro payments across Europe by removing the technical, legal and market barriers between European countries.

Banks, or more accurately “Payment Service Providers” (PSP), are expected to develop SEPA capabilities using infrastructure already in place, including Clearing and Settlement Mechanisms (CSM), and ISO20022 messaging.

The legal framework for SEPA is based on the Cross-border payments Regulation, the Payment Services Directive (PSD/PSD2), the SEPA migration end-date Regulation, and the Interchange Fee Regulation.

Broadly the objectives of SEPA are to:

• • Improve efficiency and competitiveness of the European economy
  • Reduce the time to process electronic cross-border payments from over three business days to one
  • Create a basis for further innovation and development

SEPA Credit Transfer and Direct Debits

Implementation of Credit transfer and Direct debits was started in 2008 and completed in 2016. This demonstrated that cross border payments in the SEPA area were possible and that mechanisms, such as clearing and settlement, operated as required.

Credit transfer and Direct Debit in this phase of the project aim to take no longer than one business day for electronic payment orders, two business days for paper-based payment orders.

This blueprint does not discuss direct debit payments or request to pay (RTP) requests.

SCT Inst is shorthand for SEPA Credit Transfer (Instant). SEPA Instant Credit Transfers are also referred to as SEPA Faster Payments or SEPA Instant Payments.

European Payments Council’s SEPA Instant Credit Transfer scheme (SCT Inst) improves availability and performance. This means that transfers may be initiated at any time, 24 hours a day and 365 days a year, and take no more than ten seconds between the recipient’s payment service provider (PSP) informing the payer’s PSP that the money has been received successfully and the funds being available to the recipient.

Uptake is growing, however provision of instant payments to payment account holders is not available to the same degree across all SEPA jurisdictions.

European Automated Clearing House Association (EACHA)

The European Automated Clearing House Association (EACHA) does not perform a commercial or operational role in payment processing. The organisation was established to:

• • Be a forum for members to share information
  • Advance the views of its members on issues of general interest
  • Address specific issues as and when they arise

EACHA has developed and published common guidelines for clearing and settlement of SEPA Payments. This blueprint makes extensive use of EACHA materials to explain clearing and settlement of SEPA credit transfers.

SEPA Implementation Model

SEPA aims to level the payments playing field across Europe and beyond. It introduces the idea of treating what was an international payment as a domestic payment for the participating countries and banks, and only when they are dealing in Euros. Instant payment builds on previous work to speed up clearing and settlement to ensure that a beneficiary has access to transferred funds within a short time, currently the target time is 10 seconds.

Existing Clearing and Settlement mechanisms (CSM), including SWIFT, CHAPS, National Faster Payment solutions, have been or will be modified to support SEPA payments and co-exist across participating countries.

PSPs should utilise the PSD2 application programming interfaces to […]. PSPs should clearly communicate their transaction limits that apply to outgoing and/or incoming instant payments.

Payment Service Providers (PSP) are organisations with direct connection to the scheme layer and the capability to clear and settle a payment. The term PSP takes the same meaning as in the Open Banking (PSD2/XS2) regulations and participating organisations are expected to extend capabilities and use of their Open Banking implementation to support SEPA payments.

Figure 2; Credit Transfer Overview

This blueprint follows the layered architecture pattern used by most payment solutions; End User Solution Layer, Scheme Layer, Clearing Layer, and Settlement Layer.

End-User and Scheme

The end user layer gives access to the scheme capabilities to end users. SEPA is intended for use by individuals and organisations.

Clearing and Settlement

Clearing and Settlement are two steps in the multi-step process of moving credit from one holder to another. The Payer (Originator) initiates the process by requesting funds to be transferred from their account to the payee (Beneficiary) account.

When a payer transfers funds, the clearing process validates the transaction. A clearing mechanism (CSM) ensures that there are sufficient funds to complete the purchase, and the transfer is recorded before the funds are delivered to the payee’s account. This is a multi-step procedure to settle financial transactions, ensuring ledgers remain in balance.

• • The clearing system ensures that funds are available.
  • The transaction details are recorded.
  • The funds are held securely until the transaction is complete.
  • Discrepancies are investigated, with the clearing mechanism stepping in as an intermediary.
  • The funds are cleared, and the funds are delivered to the payee.

End-User Solution Layer

We consider that the end user solution layer encompasses the mobile device or website, API layer, and interface managed functionality, including validation and consent management, security, and application firewall protection.

Supporting Request to Pay (RTP) Messages

ECN recommends that front-end solutions should incorporate the ability to send and receive SRTP messages. To ensure cross-border interoperability, services should be based on the European Payments Council’s SEPA RTP (SRTP) rulebook or migration of existing RTP solutions to the scheme.

Open Banking APIs and TPP Access to Instant Credit Transfers

The existing Open Banking platform provides most of the security, reliability, hosting, and management functions needed to give users (TPP) access to SEPA Instant Credit Transfers.

Website (manual) Access to Instant Credit Transfers

The Open Banking gateway can be modified to allow the Mizuho website to use the APIs. This approach will allow the website developers to leverage the Open Banking functionality and assure that the PSD2 website – API alignment requirements are maintained.

Scheme Layer

There are several schemes for making payments and performing other financial activity. This blueprint focuses on the SEPA scheme, which dictates rights and obligations of participants, and their customers, terms and conditions of access, and functions available from SEPA members.

The scheme demands functions that are not yet available from the clearing and settlement, or user layers, however for those functions already implemented, the payment messages use open, industry recognised standards.

Scheme compliance must ensure interoperability between participants, which means that individual participants may innovate to differentiate in the market, they may not conflict with the Rulebook.

Rulebooks are used to define all elements of the scheme.

SEPA Credit Transfer and Direct Debits

Credit transfer and Direct Debit in this phase of the project aim to take no longer than one business day for electronic payment orders, two business days for paper-based payment orders.

SEPA Direct Debit Core (SDD Core) enables regular payments for recurring obligations such as subscriptions, and bills. It provides the core functions needed to enable direct debits for consumers and organisations. SEPA Direct Debit B2B (SDD B2B) adds functions that support recurring transactions between businesses or organisations. Payment methods are similar for each but with differences in the direct debit mandate management and refund timelines.

SEPA Credit Transfer

SEPA Credit Transfer is the defining credit transfer, which is quicker than previous transfers and delivers payments across the SEPA area regardless of country, as if they are a domestic payment.

SEPA Instant Credit Transfer (SCT Inst)

SCT Inst is shorthand for SEPA Credit Transfer (Instant). SEPA Instant Credit Transfers are also referred to as SEPA Faster Payments or SEPA Instant Payments

SEPA Direct Debits

SEPA Direct Debit Core (SDD Core) enables regular payments for recurring obligations such as subscriptions, and bills. It provides the core functions needed to enable direct debits for consumers and organisations. SEPA Direct Debit B2B (SDD B2B) adds functions that support recurring transactions between businesses or organisations.

Payment methods are similar but with differences in the direct debit mandate management and refund timelines.

SEPA Direct Debit Core (SDD Core)

A SEPA direct debit core (SDD core) is a payment pulled and debited from the payer (debtor) account and credited to the payee’s (creditor) account. These payments require a mandate from the payer to the payee to authorise the payee (creditor) to debit the payer’s (debtor’s) account when pre-agreed conditions are met.

DD mandates are identified by a unique mandate reference (or UMR). The creditor is identified by a creditor identifier, which is usually assigned by the national bank of the country of the creditor.

The payment must be initiated between two weeks and two business days before its due date. It can be rejected by the debtor’s bank until five days after its due date, for instance if the account has been closed.

The debtor needs to be notified two weeks in advance of the settlement date unless the debtor explicitly waives the notification.

A SEPA direct debit (SDD core) can be refunded up to eight weeks after execution. In that period, a refund can be requested even if there was a valid mandate and even if the payment had been authorised.

A refund can be then requested for up to 13 months after execution if there was no valid mandate, or if the payment was not authorised.

SEPA Direct Debit B2B (SDD B2B)

SDD B2B payments cannot be processed until a mandate is agreed between the parties and registered by the debtor’s PSP. This requirement does not apply to SDD core payments.

The debtor’s PSP must verify that a SEPA direct debit B2B corresponds to a valid mandate before executing the payment and debiting the debtor’s account. This additional step allows the scheme to assure that there is a valid and authorised mandate and thus, a SEPA direct debit B2B payment cannot be refunded by the payer.

A SEPA direct debit B2B payment must be initiated between two weeks and one business day before its due date. Pre-notification of the debtor is not required.

SDD B2B payments can be refunded up to 13 months after execution if there was no valid mandate or if it was not authorised.

The debtor’s PSP may still return the payment up to three days after the execution for technical reasons or because the debtor PSP is unable to accept the collection for other reasons, such as the account being closed, the customer being deceased, the account not accepting direct debit, or the debtor refusing the debit.

Clearing Layer

Arrangements for the clearing of transactions between PSPs.

The clearing process follows European Payment Council defined SCT Inst message flows and supports SCT Inst requests to pass through one or more Clearing and Settlement Mechanism (CSM) between the Originator PSP and the Beneficiary PSP. Each CSM can be provided by a different organisation. PACS.008 messages are used to initiate payment, and PACS.002 to respond and feedback.

Figure 3; Mandatory Scope of EPC scheme

In the figure above, the payment (SCT Inst) is passed between the Originating Clearing and Settlement Mechanism (OCSM) and the Beneficiary Clearing and Settlement Mechanism (BCSM). The sequence of operations in the model will be as follows:

1 – On receipt of an instant payment instruction from its Originating customer, The Originator initiates a credit transfer initiation message to the Originator PSP, using either a pain.001 or similar (proprietary) message in accordance with an agreement with its PSP.

2 – Based on the credit transfer initiation message, the Originator PSP sends a SCT Inst (pacs.008) to OCSM.

3 – OCSM forwards the SCT Inst (pacs.008) to BCSM with a Reconciliation Reference (see section 3.4.8).

4 – BCSM forwards the SCT Inst (pacs.008) to the Beneficiary PSP.

5 – The Beneficiary PSP validates the SCT Inst (pacs.008) and sends a positive/negative status report (pacs.002) message back to BCSM to confirm that the message was valid / invalid.

6 – BCSM then delivers that status report (pacs.002) message to OCSM. At the same time, the BCSM sends the positive status report (pacs.002) message to the Beneficiary PSP to ensure that it is certain that its response has been received by BCSM. Content of pacs.002 sent to OCSM and BPSP by BCSM will be identical to the one received from the BPSP with the Reconciliation Reference.

7 – OCSM delivers the received status report (pacs.002) to the Originator PSP.

8 – The Originator PSP processes the positive / negative pacs.002 as appropriate, including an immediate response to the Originator if it is a negative response.

9 – Originator PSP responds to its Originating Customer as agreed with its customer.

RTP-based payment solutions can reduce dependencies on cards and enhance competition. RTP can be widely used in POI payment situations (either face-to-face or remotely), helping PSPs to develop payment solutions that eliminate the need to pay card processing or card scheme fees.

Settlement Layer

Clearing and Settlement Mechanisms (CSM) must use a single procedure for the settlement of pan-European instant payments. The default mechanism requires PSPs to pre-fund settlement of instant payments in cash. CSMs may optionally agree bilaterally to transfer liquidity on a post rather than prefunding basis, and how they will manage counter party risk.

Transfer of Equity (pre or post payment)

Pre-funding will be supported by the TARGET 2 Ancillary System Interface (ASI). The ASI6 Realtime procedure will be used to manage the prefunded balances of PSPs via a single TARGET2 technical account per CSM. The single procedure means that all instant payments are settled in real time, including intra CSM payments.

Target 2 (Decommissioned) Replaced by T2

During T2 opening hours, CSMs will transfer prefunded liquidity to the technical accounts of the CSMs they are connected to, to fund the inter CSM payments they are making. Physical handling of these transfers is out of scope for this blueprint.

T2 is the real-time gross settlement (RTGS) system owned and operated by the Eurosystem. Central banks and commercial banks can submit payment orders in euro to T2, where they are processed and settled in central bank money, i.e. money held in an account with a central bank.

(https://www.ecb.europa.eu/paym/target/target2/html/index.en.html)

RT1

The RT1 System is a real-time gross settlement payment system for the execution of SEPA Instant Credit Transfers (SCT Inst) at a pan-European level. The payment system operates around the clock on every day of the year.

RT1 supports payment service providers in transferring euro transactions between payment accounts in a few seconds end to end, with immediate availability of the payment amount to the beneficiary. Transactions between RT1 participants are processed on average in just over one second.

Financial institutions from all over Europe can use RT1 for any payment in euro that is fully compliant with the SCT Inst Scheme of the European Payments Council (EPC) and is in line with the ISO 20022 global messaging standards for real-time payments.

(https://www.ebaclearing.eu/services/rt1/overview/ )

SWIFT

SWIFT has a faster payments capability that can be leveraged for SEPA payments.

The Society for Worldwide Interbank Financial Telecommunications (SWIFT) system powers most international money and security transfers. SWIFT is a vast messaging network used by financial institutions to quickly, accurately, and securely send and receive information, such as money transfer instructions.

Financial institutions use SWIFT to securely transmit information and instructions through a standardized code system. Although SWIFT is crucial to global financial infrastructure, it is not a financial institution. SWIFT does not hold or transfer assets but facilitates secure, efficient communication between member institutions.

Cross Cutting Design Considerations

Cross-cutting concerns those issues and features that will impact and affect all or many aspects of an enterprise, or multiple organisations within the same level; therefore, require attention and consideration in your enterprise architecture design.

For discussion of SEPA cross-cutting design considerations, we see these to be of note:

1. Transaction volumes and charges
2. Enhanced risk management
3. User experience
4. Reuse capability
5. Timeouts and actions

Transaction Volumes and Charges

Instant payments can be used in all payment situations may replace other payment methods, such as card payments or direct debits. Instant payments may be used more frequently than traditional credit transfers, especially for micro-payments. Eurosystem discourages but does not prohibit payment transaction charges.

Design Point: The high volume, mixed value nature of these payments may require differentiated handling for fraud detection. Systems must be capable of scaling to accommodate higher than “expected” volumes.

Design Point: Systems must be capable of handling charges and everything that entails.

Enhanced Risk Management

Anti-Money Laundering (AML) and fraud monitoring systems must support a good customer experience while meeting challenges from the real-time, 24/7 operation of instant payments. Specific areas of concern are (1) minimising false positive AML sanctions screening hits, (2) enhanced “scamming and phishing” attack detection, and (3) user defined credit and payment limits.

To address these concerns, the following mechanisms can be added:

• Confirmation of Payee
• Consent management including payment limits.
• Consent to Geographic policy (e.g. payments cannot be made to France. Only Germany and UK banks.)

User Experience

PSPs should develop customer front-end solutions (Website and Mobile Applications) that offer a secure payment experience using predefined and new beneficiary IBANs (entered manually, by NFC or scan) with instant user notifications and additional functions compared with traditional credit transfers.

Reuse

PSPs should utilise PSD2 application programming interfaces to share information, process operations and carry out authentication in a frictionless way efficiently and securely. (ECB Recommendation)

Timeouts and Actions

Solution Overview – Implementing SEPA

As discussed, SEPA payments, including Credit Transfer, Direct Debit, and SCT Inst all take advantage of existing infrastructure (specifically clearing and settlement mechanisms, and payment infrastructure implemented for PSD2/XS2) for implementation.

The scheme builds on these existing capabilities with tighter demands for reduced latency and treatment of cross border credit transfers withing the SEPA area.

This means that many of the parts of the infrastructure need to be modified or extended to support the “instant” part of the requirement for SCT Inst payments.

External Perspective (SCT Inst)

The external perspective ignores mechanisms for processing payments that are internal to the PSP to concentrate on the external triggers and responses from the various parties.

Figure 4; Infrastructure required by SEPA payments

The figure above shows how a payment is initiated by the payer bank and processed by the payee bank. Use Cases (UC-n.n) indicated on the diagram are described below.

Confirmation of Payee

“Payee Confirmation” indicates a request from the payer bank to fetch the account name for the payee bank account. The name is checked against the payer’s input name and the status of the match presented to the payer to consent to the payment proceeding.

UC-1.0 Outbound SEPA Credit Transfer (Instant Payments)

Outbound payment instructions are those triggered by TPP or PSP internal requests and that then pass “outbound” through the payments gateway. These requests become “inbound” requests for the counter party bank.

UC-1.1 Third Party Payment Provider (TPP) initiation of a faster payment

For this case, the payer (Originator) uses a TPP hosted application to make a payment.

The payment is secured and transmitted to the bank using existing Open Banking functionality. Reusing this mechanism allows us to be sure that security is applied, and that the payment is properly transmitted to the banks internal systems.

The user must be able to give consent for the payment, to provide value limits, and to confirm the payee’s name details are acceptable. The application must support these features, as well as managing responses from the payee (Benefactor).

In this case, a request is received to make a payment from an account that is not held with the current bank. This case is not supported.

UC-1.1 First-party initiation of a faster payment

This case the payee has authenticated and accessed the bank’s website and is directly making the payment. In all other respects the requirements are the same as for UC-1.0

UC-1.2 Payments should behave as if domestic

SEPA payments are made between two parties, each identified by an IBAN. For domestic payments IBAN numbers should be in the same domicile, which is a single country.

SEPA extends the domicile to include all participating countries, and by extension the IBANs in those countries. This means that the domestic payment API for Open Banking must be capable of performing a domestic payment in the SEPA area given the rule constraints of value and currency.

US-1.3 Confirmation of payee

The payer must be given the option to confirm the payee name is acceptable to authorise the payment.

UC-2.0 Inbound SEPA Credit Transfer (Instant Payments)

Inbound payment instructions are those triggered by another PSP and that then pass “inbound” through the payments gateway. These requests are “outbound” requests for the counter party bank.

UC-2.1 Clearing and settlement

For this case, the payer (Originator) is interacting with a different PSP and requesting to make a payment into an account held by the current PSP. The request will come though the Clearing and Settlement system and must be rejected or accepted quickly. The funds must be available to the beneficiary within 10 seconds of request being made by the originator.

UC-3.0 Core Banking and Payment Systems

Core banking and payment systems must be capable of prioritising faster payments, and providing functionality required to support them continuously.

UC-3.1 Checks required to allow an outbound payment (Account balance, Status, and balance update)

Allow the Open Banking gateway to check the account is allowed to initiate a payment. Make the ledger entries required to reflect the payment.

UC-3.2 Checks required to allow an inbound payment (Account Status, and balance update)

Allow the Open Banking gateway to check the account is allowed to receive a payment. Make the ledger entries required to reflect the payment.

UC-4.0 SEPA Credit Transfer and Direct Debits

SEPA Credit Transfer and Direct Debits is likely to be implemented inside the bank for “normal” operations. Many UK banks implemented only what was required by the PSD2/XS2 regulation, which depended heavily on what was already available through their website. This means that some banks may not have implemented request to pay (RTP) in the form of Open Banking APIs, which functionality required for direct debits.

UC-4.1 Support RTP and mandate requests from the user layer

Request to pay and the dialogue for B2B and individual consumers is required to allow direct debit mandates to be registered and authorised, as well as RTP requests to demand a payment. Additional APIs may also be implemented to reject a DD payment that should not have been allowed.

Internal Perspective

The internal perspective illustrates the capabilities needed to support SEPA credit transfers and direct debits, including instant payments. The figure below shows three parts to the landscape, including the user layer, core banking layer, and settlement payment infrastructure.

Figure 5; Internal Perspective

User Layer [1]

The Open Banking Gateway required by PSD2/XS2 regulation will support one of the EU Open Banking protocols and API catalogue. The gateway must operate at least for the hours that the PSP website allows payments and will therefore implement most of what is needed to provide SEPA payments.

Modifications may be needed to add features that may not be already implemented. For example:

Support for confirmation of payee (optional in open banking)

Recognition of candidate payments for SEPA SCT Int processing and tagging them

Modification for domestic payments in the SEPA area

Additional logic to support cross currency charges and payments in the SEPA area.

Extension of operational hours to 7×24

Functions provided by a typical Open Banking Gateway are accessed by TPP organisations that have the correct credentials issued by the relevant (country specific) Open Banking organisation.

Core Banking Systems [2]

The core banking systems maintain track of user accounts and must be consulted to determine that an account is properly configured to send or receive funds, and to record all activity. The core banking layer in most UK banks does not operate 7×24 and may not prioritise payments in the ways needed for SEPA.

Modifications are needed to add support for 7×24 and to prioritise and properly handle SEPA payments.

Payment Infrastructure [3]

The payment gateway selects between different clearing and settlement pathways and is the first point of receipt for inbound payments.

Modifications are needed to pass responses to SEPA payments directly to the BSB to reduce latency, and to properly select a CSM for SEPA payments.

Blueprint

Attempting to develop a general blueprint for SEPA implementation was always going to be audacious. The approach here is to consider the existing infrastructure that is likely to be present in a functioning bank (PSP) and to provide broad guidance in the form of a checklist for each of the critical areas. As already noted, request to pay and direct debit mandate handling is not covered by this blueprint, neither is the detail of currency exchange.

The SEPA scheme specifies service levels and use of protocols that layer naturally over, and build upon, existing payments infrastructure typical of a PSP. All aspects of the infrastructure involved in SEPA payments must:

• Be available 7×24 and prioritise payments to avoid unpredictable delays.

This blueprint is not comprehensive. Please contact Responsiv (Responsiv.co.uk/contact-us) for any questions arising from this blueprint.

User Layer – Payment Instruction Acquisition

The user layer is responsible for acquisition of a payment request, identifying it as a candidate for SCT or SCT Inst, and performing the tasks required to allow it to be processed as an SCT payment.

SCT Identification

Payments suitable for clearing and settling using SEPA Credit Transfers must:

1. Originator and beneficiary must be accounts held by SEPA area PSPs.
2. Transfer must be in EUR and below the PSP ceiling threshold or €100,000 whichever is appropriate.
3. Originator must have authorised the Confirmation of Payee request.

For PSP with existing Open Banking APIs, we recommend logic be added to the domestic payment and international payment APIs to

1. Identify candidate payments and add meta data to inform downstream systems that this is a SEPA payment. This will allow changes to those systems to add features needed by SEPA payments.
2. If accounts are not EUR accounts, then the charges/exchange rates need to be handled by the Open Banking layer.

It may also be desirable to allow users of the Open Banking APIs to explicitly request SEPA handling and settlement rules. Payments already identified for SCT processing may be automatically elevated to SCT Inst if they conform to the policy.

Core Banking – Payment Instruction Processing

The user layer will create a payment that is tagged as SCT or SCT Inst and containing the information required to process, clear, and settle the payment. The core banking systems must now process the payment.

SEPA Pre-Payment

SEPA Pre-payment is a mechanism offered by the clearing and settlement mechanism to allow the CSM layer to guarantee funds to the beneficiary if they accept the payment. It is a mechanism that requires the originator PSP to maintain sufficient funds to cover payment activity.

1. Check available pre-payment funds and top up as needed.

Core Banking System

This system generally holds the account details and ledgers for each account holder.

The originator account must:

Be of the right currency

Have sufficient available funds for the payment.

AML and other checks passed.

Funds marked.

Payment Request sent to Payment Infrastructure

The beneficiary account for inbound and internal payment requests must:

1. AML and other checks passed.
2. Be of the correct and expected currency.

Payment Infrastructure – Payment Instruction Clearing and Settlement

The core banking payment instruction processing will hand a SEPA marked payment to the payment infrastructure, which may perform additional security checks. For outbound payments, the payment infrastructure will:

1. Remove any internal SEPA tags and submit the payment for clearing and settlement.
2. Receive the response and send a copy directly to the user layer, and to the core systems.

For Prepayment requests the payment infrastructure will:

1. Process the request and response. This uses different messages from a standard payment.

Incoming SEPA requests must be prioritised, and settlement is against the prepayment account rather than the normal mechanism.

Using Responsiv

Responsiv has decades of experience working in financial services, including insurance, investment banking, consumer banking and card payments.  We designed, built, host, and manage Open Banking services for one the world’s largest banks and have experience designing event-orientated payment systems.

Responsiv can accelerate your adoption of SEPA.

Utilise our experience of designing and building payments solutions that make best use of existing capabilities and partners currently in place.  We deliver to time and budget and often back our commitments with fixed price delivery contracts.

We have a set of accelerators (see below) that speed up delivery of your SEPA capability.  Risk is reduced by using existing banking infrastructure alongside our products.  This approach needs less configuration and tailoring than a bespoke solution, whilst being adaptable to your unique existing environment.

Using Responsiv Product Accelerators

You can use Responsiv to support for your SEPA implementation project in many ways depending on your existing infrastructure and appetite.

Consulting Services

Responsiv Consulting provide services ranging from business analysis and business consulting, through subject matter expertise, design, and implementation services. Our consultants can augment your project teams with skilled practitioners backed by Responsiv know-how or can take full responsibility for delivery of parts of your SEPA capability. We have accelerators and methods, that are optional. We are here to make you successful.

We can help in the following ways:

• • Readiness review for SEPA Instant Payments

We work with your business and payments specialist to understand the infrastructure already available and your planned level of SEPA compliance. Our report presents a gap analysis of current versus needed capabilities with recommendations.

• • Design and implement SEPA Instant Payments

We work with your IT people to design the processes and changes needed to implement SEPA, including changes to business practice (for example the impact of pre-payments). We can design this using our products to accelerate delivery and reduce risk or follow your lead on approach and preferred implementation details.

• • Project Assurance

We work with you as the ‘critical friend’ through the phases of delivery design, implementation and run.

• • Managed Service

We implement monitoring directly onto our products deployed to your infrastructure or provide a second line of support available to your existing service desk, removing the need to build one-off skills and capabilities.

Open Banking Assets

Responsiv has experience with Open banking API development and operate a cloud based Open banking gateway. Our Responsiv Cloud Open Banking Gateway is a reliable service that can be used to host API libraries that support various versions and API standards for banking.

Payment Infrastructure

Responsiv can provide you with the software and services to implement the IBM Financial Transaction Manager.

IBM FTM for SWIFT Services is a fully certified SWIFT messaging interface (SWIFTNet FIN, Interact, FileAct and RMA) that is already capable of delivering the benefits in the changing world of SWIFT.

Alternatively, we can augment your existing payment infrastructure with Responsiv products and consulting, including our advanced integration platform.

Support and Maintenance

All Responsiv products include 12 months or full-term support and subscription. This entitles you to raise problem tickets with our service desk, and to download and use any patches and upgrades published during the term. We offer an advanced support product that entitles you to connect your Responsiv Unity enabled software directly to our service desk, and includes patch and upgrade installations, as well as mentoring and administrator support services.

Our consulting services can also have a warranty period using Responsiv Assist Hypercare Support. This is an optional way to have consulting deliveries supported after the project team has finished and moved on to other projects.

Summary and Conclusion

There are many outstanding questions that this blueprint does not include. The intention is to provide a flexible and thought-provoking summary of the SEPA scheme, and the capabilities that a PSP needs to implement it.

The scheme builds on open banking and existing clearing and settlement infrastructure, which leaves the challenges illustrated here. The technology changes are focused in the following areas:

• • Enhancement of existing open banking functionality.
  • Reconfiguration of core systems to support 7×24 and prioritise payments.
  • Introduction of mechanisms for pre-funding SEPA (SCT Inst) payments.
  • Modification of the payment gateway to properly handle incoming SEPA requests.

Other areas that must not be forgotten are to review the risks specific to instant settlement, and policies for pre-settlement funding.

Enhancement of existing open banking functionality

We expect this to be done over a period of 6-9 months and incrementally released to manage the risk to existing functionality and give proper time for investigation, functional testing, documentation, and acceptance (UAT) testing.

Reconfiguration of core systems to support 7×24 and prioritise payments

Responsiv is not able to make changes to these systems. We can support the systems analysis and design phases of the project, which will support our work in other areas as well as being valuable to the implementation team.

Introduction of mechanisms for pre-funding SEPA (SCT Inst) payments

Responsiv can implement this functionality subject to existing arrangements. We will investigate the message formats and expected dialogues before designing and developing a system to manage the situation and operate according to policies set into the system (through a user interface).

Modification of the payment gateway to properly handle incoming SEPA requests

The payment gateway is partially known to Responsiv. We can support changes to the SWIFT gateway and help systems analysis and decisions regarding other CSM interfaces. The BSB or another ESB can be used to integrate with core systems.

Conclusion

Responsiv consider that the project will likely take significant time to properly investigate and make changes to core banking systems. Changes to the SPG and CSM gateways should be quicker.