RBNZ Payment Systems Replacement

Transcription

1 RBNZ Payment Systems Replacement NZClear Functional Change Confirmation 6 July 2017 Ref #Error! Unknown document property name. verror! Unknown document property name.

2 NZClear Functional Changes Background A proposed changes paper was socialised with NZClear members on 13 April, inviting submissions on the Bank s intent to change or not provision certain functionality in the NZClear replacement system. The key areas of change are summarised as follows:- Functionality not provisioned: Cash Payments FINEWISS (Fixed Interest Issuance) FX Entry Host to Host Lite (File upload) Security deal pricing Changes to functionality: NZClear/Swift interface Corporate Actions processing Member Account Structure Reporting Settlement The full details of the proposed changes documented in the consultation paper are attached as Appendix 1. Summary of Decisions After consideration of the submissions received and completion of an assessment process the following decisions have been made in regards to continued provision of services: Cash payments Not provisioned. Current CASHP functionality to be retired from NZClear system 30 June FINEWISS - Not provisioned. Current FINEWISS functionality to be retired from NZClear system 31 January FXENTRY Not provisioned. Current FX functionality to be retired from NZClear system immediately. Host to Host Lite - Not provisioned. Current functionality to remain available in NZClear system until go-live. Security deal pricing - Not provisioned. Current functionality to remain available in NZClear system until go-live.

3 The changes to functionality components detailed in the consultation paper will now be fully documented and discussed with members through operational workshops. A timeline for the workshops will be confirmed by 31 July If you have any questions in regards to the decisions, please contact Nathan Lewer on the details below:- Nathan Lewer Stakeholder Liaison and Sector Readiness Manager PSR Programme Telephone Mobile nathan.lewer@rbnz.govt.nz The assessment process and rationale behind the decisions is outlined below. Assessment/Rationale of changes A total of 22 submissions were received across the 10 key change areas. There were a number of high quality submissions, with considerable thought given to the responses. The response content reflected our expectations of the impact, and the Payment Systems Replacement (PSR) team did not receive any surprises through the written responses. The views expressed very much aligned to our initial thoughts when tabling the proposed changes. As expected the concentration was around Cash Payments, FINEWISS and HTH Lite (file upload facility). Assessment Approach In finalising the solution design, a number of factors contributed to the assessment of the submissions:- Stakeholder discussions i.e. Settlement Bank working group Face to Face interviews with key contributors to submission process Statistical analysis of current functionality use Strategic approach to provision of services Stakeholder discussions/face to Face Interviews In order to understand the member requirements and impact on members, as well as the alternatives available for use in the market, a series of Stakeholder meetings were conducted. These included the key respondents to the submission process, regular users of the CASHP function and Settlement banks providing intraday limits and cash clearing facilities for NZClear members. The nature of these meetings was to confirm the approach of the Bank in arriving at the proposed changes, and to seek further detail on the payment activity currently transacted in the system and its origins. To replay the key messages from RBNZ in these discussions, below is the outline approach. Statistical Statistical analysis was carried out on the affected functionality to better understand its use and current volumes.

4 Strategic approach to provision of services In retaining the role of system operator of NZClear services, the Bank closely examined the key deliverables of the CSD service provision. Notwithstanding the current functionality provided, in purchasing a vendor CSD product, it was the primary intent of the Bank to align with standard services of the system and, where possible, avoid bespoke developments to mirror services not characteristic to a CSD, and where alternate solutions exist currently in the market. As communicated these services focussed in particular on the following : Cash Payments FINEWISS (Fixed Interest Issuance) Host to Host Lite (File upload) In selecting the Perago CSD and assessing the available functionality to meet our requirements, it is important to note that the key areas of straight Cash payments, Fixed Interest Issuance and a flat file upload facility are not included in the core system, nor do they feature on the Vendor roadmap for future developments. It is therefore an exercise of assessing the current use, its impact on the effective operation of the CSD and viable alternatives available in the market. These factors would ultimately dictate if a valid business case exists to proceed with developing a bespoke solution for our market. Findings Cash Payments Statistical - CASHP Statistical analysis was carried out on cash transactional data over a three month period from Feb 17-Apr 17. This focussed on the total volumes through the current CASHP function as well as specific analysis of the key contributors to the submission process and the higher volume users. The below table illustrates the average daily volumes and values over the 3 month period Feb to Apr 17. It provides a breakdown of where the payments are either between 2 ESAS account holders or an ESAS account holder is the Payer, representing 54.98% of all payments made via CASHP. Volume % of total Ave. Daily Value Ave. Daily % of total $ 177,328,519, $ 3,005,568, ESAS parties % 41 $ 47,788,657, $ 809,977, % 1 ESAS party % 102 $ 108,966,192, $ 1,846,884, % - ESAS Payer % $ 43,376,757, $ 735,199, % NO ESAS % 18 $ 20,573,669, $ 348,706, % Further analysis of the individual member transactions indicate that a high percentage of payments made via CASHP are for Issuance, Dividends or Corporate Action related activities. This has been confirmed in the discussions with Registrars and members. In meeting service requirements, the bank is fully engaged to cater for all core CSD processing functions and activities, including the cash payments associated with these functions. This will be achieved through system embedded processes catering for the following:-

5 Lodgement of securities Security trading DVP model 1 for FI and Equity trades Coupon/Interest payments Corporate actions Maturity payments Individual analysis was carried out at a member level and the top 10 users (volume wise) are represented in the table below:- # of Transactions (Payer or Receiver) # of transactions as Payer Ave. daily volume as Payer Member Member Type Ave. daily value Ave. daily value as Payer 1 Custodian $ 8,977, $ 9,447, % 2 Custodian $ 4,416, $ 4,386, % 3 Corporate $ 34,258, $ 40,787, % 4 Corporate $ 1,592, $ 850, % 5 Broker $ 2,194, $ 893, % 6 Bank $ 16,860, $ 13,173, % 7 Corporate $ 11,850, $ 11,618, % 8 Bank $ 19,305, $ 16,049, % 9 Broker $ 269, $ 275, % 10 Custodian $ 2,395, $ 774, % From a wider market perspective, the utilisation of established payment channels realises the following :- % of total cash payments Increased usability of cash intraday by utilising external bank accounts Removal of bespoke functionality mirroring the more routine and governed channels Settlement bank appetite to use existing channels in order to integrate fully with internal systems Increased visibility of payments in market wide statistics and analysis i.e. RBNZ, PNZ Decision Our discussions with the above stakeholders have confirmed the majority of the CASHP transactions on their member accounts originate from Interbank loans, FX and Swap payments and Term Deposits all activities with no direct relationship to our core CSD activities. It is therefore the decision of RBNZ as system operator to no longer provide a Cash payment facility within the replacement NZClear system. It is also the intent of the Bank to phase out the use of the CASHP function in the current system with a targeted functional retirement date of 30 June 2018.

6 FINEWISS (Fixed Interest Issuance) Statistical - FINEWISS The below table represents the current usage of the FINEWISS function in NZClear:- Volume % of total Average # per month Bank % Bank % Bank % Bank % Bank % 8.18 Bank % 6.55 Bank % 2.36 Bank % 1.09 Bank % 1.09 Bank % 1.09 Bank % 0.82 Bank % 0.36 Bank % 0.09 Decision Discussions with the registries have confirmed their current ability to provide Fixed Interest issuance to the banks that currently utilise the FINEWISS function in NZClear. The Registries have confirmed they can receive an ed Issuance request which will be completed, notified to RBNZ and lodged to the NZClear account for trading within a timeframe considered reasonable by RBNZ. An SLA will be agreed between RBNZ and the Registrars for the processing functions after further discussions with the current users. We would however encourage bilateral discussions between yourselves and your chosen Registrar at your earliest convenience. The RBNZ as system operator will not provide an issuance facility in the replacement NZClear system, and will retire the FINEWISS function in the current system by 31 January FX Entry This functionality has not been used in the current NZClear for the past 12 months and therefore will not be provisioned for in the replacement NZClear system. The function will be retired from the current system immediately.

7 Host to Host Lite (HTHL - File upload) Statistical HTHL Member Number of trades Average Daily Trades % of total HTHL trades % of ALL trades % 6.76% % 3.77% % 2.91% % 1.18% % 0.94% % 0.51% % 0.23% % 0.21% % 0.16% % 0.07% As indicated above the concentration of trade input via HTHL is centred round the 3 top users, accounting for 78.95% of the total HTHL traffic. In the context of overall trade input to the system, this is somewhat lower with the top 5 members contributing to just over 15% of the total trade traffic. Decision Although the functionality is heavily used by a small number of members, the combination of the strategic direction of the core services offered by the Bank, coupled with a desire for the most secure payments environment possible, have led the Bank to decide that the Host to Host Lite function will not be simulated in the replacement NZClear system. With the emergence of products such as SWIFT Lite and third party SWIFT service providers since the introduction of the function into NZClear, we would encourage use of one of these solutions. The Bank is happy to assist members with discussions with SWIFT on the SWIFT Lite product if required. The HTHL function will remain available in the current system until go-live. Security deal pricing A small subset of members currently use the system calculated deal price as a final check on trade input (manual input via GUI only). As we see the majority of trades submitted via the SWIFT interface, and the nature of the system being a settlement system of dealt trades, the absence of the security deal price will have minimal impact on members. Decision The functionality will not be catered for in the replacement NZClear solution but will remain available in the current system until go-live.

8 Appendix 1: Consultation Paper Apr 2017 NZClear Proposed Functional Changes As the CSD Planning & Clarification requirements phase nears completion, the Bank is considering options for the most efficient and seamless implementation of the replacement system. Whilst the overall approach is to minimise the extent of change for members where it makes sense to do so, there are however a number of areas where we envisage operational changes will be required at a member level, and we would like to present these for your consideration and comment. These areas of change arise as we work towards the core principle of a more standardised CSD solution, relying less on bespoke customisations and aligning our service with core CSD functionality. To ensure an efficient implementation we have focussed on provisioning for current service requirements for the core CSD functionality with value add or further development to be included in a post go-live roadmap (details follow below). We welcome your feedback and comments to psr@rbnz.govt.nz by no later than COB Friday 12 May The following represent functionality not to be provisioned in the CSD replacement, being seen as not core CSD functionality. Cash Payments NZClear currently provides a cash payment facility for members to make payments to each other via the system. These payments flow up through ESAS (after satisfying NZClear member limits) and are therefore deemed real-time and irrevocable once settled. Straight cash payments between members are not viewed as a core CSD function. While the system is developed to handle the cash transactions arising from security trades, corporate actions, interest and maturity payments, cash payments between members should be directed through established payment channels already in existence in the NZ market. Rationale Whilst we understand the convenience of payments via NZClear, we are supportive of the wider NZ payments landscape and are supportive of these member to member payments being directed through existing payment channels i.e. SBI, SCP, AVP. In the first instance, your clearing bank will be well placed to assist you with explaining these channel options as they look to encourage wider use of self-serve options available to their customers. The CASHP/CASH R function was introduced prior to other electronic channels becoming available, and we believe these other, newer, channels will meet users needs. We intend to phase out cash payments within NZClear ahead of the planned go-live date. As part of our RTGS development, we are also forming a Clearing Bank working group who will work together to ensure the efficient and effective access to the required payment types for their customers. We will work with members and their clearing banks to ensure all options are clearly understood and that the transition is smooth.

9 FINEWISS (Bank Issued paper) NZClear currently offers registry services for bank issued RCD s. This allows banks to set up and issue their own debt instruments through the system without the need of an external registry. The current process for NZClear held securities issuance is largely done through external registries i.e. CISL and LINK. They obtain a term sheet from the issuer and set up at the registry prior to notifying NZClear for set up within the system. The FINEWISS process bypasses this step providing efficiencies for banks that are party to the FINEWISS agreement. Current volumes average 125 per month across 9 issuers, peaking at for an individual issuer. Rationale Again, this functionality is not seen as a core CSD function performed by the Central Bank. Given the volume of issuance, the use of the existing security issuance process through the registries will be utilised. We will look to transition issuers across to the registries with an intended cease date of FINEWISS of 31 March Host-to-Host Lite (HTHL) NZClear members currently have a file upload facility as an alternative to SWIFT, whereby they can upload CSV files of trades directly into NZClear. This feature was a bespoke development for NZClear. There are currently 10 members who have HTHL capability, 5 of which also have SWIFT capability and utilise the NZClear/SWIFT interface. Rationale With the emergence of products such as SWIFT Lite, HTHL members will be encouraged to assess those tools as an option to enable use of the NZClear/SWIFT interface. The current upload facility is likely to require the existence of more controls in members environments and SWIFT delivers superior security for members submitting data to the settlement application. FX Entry NZClear currently accommodates FX deal entry, with settlement of the NZD leg available. A small number of members used NZClear for FX trade matching and settlement of the NZD leg. Volumes have reduced over time and the function has not been used for 12 months. Rationale FX entry will not be available in the new CSD. The function will be removed from NZClear by 30 September 2017

10 Securities deal pricing When entering a security trade in NZClear via the GUI, the system utilises embedded algorithms along with daily yield curves to provide a deal consideration. It also reverse calculates a deal yield if the face value and consideration is entered. The consideration or deal yield calculated by the system is used by members as a cross check to their deal instruction. It also allows the field to be accepted rather than requiring the member to re-type the figures. Rationale In line with providing a core security settlement system, the Perago CSD will not store pricing algorithms and therefore all deal entry fields via the GUI will require an entry. In dealing with dealt trades, we see the calculation as more a trading system function, whereby the consideration has been agreed at the trading level. Also, this calculation is considered redundant for the trades submitted to the system by member automatically via SWIFT (over 52% of all trades are submitted via that channel). The below represent changes in functionality which may require member operational changes. NZClear/SWIFT Interface (NSI) The NSI is widely used by members to facilitate the STP of trade instructions into NZClear. Using SWIFT messaging to enable trade entry, receive trade status and manage statement requests, NSI is a key feature to be retained in the replacement system. The NSI will continue to use the same message set it currently utilises within NZClear, however the fields within some of these messages will change. With the adoption if a new system, deal entry fields requirements differ from NZClear. In order to accommodate this, a change in field detail is required on some messaging. Full details of the individual message constructs will be circulated to members after completion of the analysis and design phase September Members will be required to join a new NSI Closed User Group (CUG) to utilise the interface. This has the advantage of not requiring RMA agreements and billing SWIFT messaging costs for transactions will be handled direct from SWIFT. RBNZ will cease charging the SWIFT messaging component for NSI trades to members). Further details will follow later this year and we will look to enrol current members progressively to the NSI CUG through Q Corporate Actions Processing NZClear currently provides for the following Corporate Action processing within the system:- Recording of Corporate Action events including all relevant dates

11 Entitlement calculation, processing and payment for Dividends (including supplementary dividends, DRP and allocation of imputation credits, Rights Issues and Bonus Issues Member elections for some voluntary events In order to gain processing efficiencies, the replacement system will allow members to enter elective information for the following action types in the system:- Dividends DRP and supplementary Rights Issues Bonus Issues Share Splits Approved Issuer Levy Special Electives i.e. Bond Rollovers etc All dividend information i.e. Imputation credits and excluded income will also be held on the dividend announcement allowing Dividend statements to be a standard report (run by members) on the system. The system possesses the ability to handle SWIFT messaging for CA events, but to minimise the impact for go-live, this functionality will be considered in a post go-live phase. Member Account Structure NZClear currently operates a member structure including branch accounts beneath the Owning entity. It also adopts branch relationships creating efficiencies in access to both branch accounts and associated member accounts. The Perago CSD has a flat account structure where each mnemonic will be an individual account i.e. no branch accounts sitting beneath the Owner. The relationships will be handled by adopting an Authorised Agent role, effectively linking the accounts and replicating the branch relationship attributes in NZClear today. Each account in the system can have sub accounts which mirror the current HOUSE, REPO etc account purposes Each account in the Perago CSD can have a single bank account for settlement i.e. the current ability to have a bank account for different purposes will not be available. The below are confirmed benefits of the new system. Reporting NZClear currently provides a range of standard reporting in a limited range of output formats. Ad hoc requests or older archive requests require RBNZ to produce for members, resulting in time and often cost impacts. Perago adopt a Business Intelligence (BI) model which we intend to expose to members. As well as a standard suite of CSD reports available via the GUI, the BI module utilises cubes of data to allow

12 members to construct their own real-time reporting via filters and carries the ability to output in a range of formats i.e. CSV, PDF and Excel. Settlement NZClear currently adopts DVP Model 1settlement for all trades settled in the system. Members operate a Cash account in the system with an intraday limit granted by their Clearing Bank. DVP Model 1 settlement will continue for all trades in the new system. The current cash account and intraday limit model will also be retained as it currently operates. Post Go-live Roadmap In parallel with the Perago roadmap (where the system features are continually enhanced), RBNZ would like to provide members with the ability to submit development requests for consideration in subsequent releases. This will be achieved with the introduction of an on-line submission form available to members (available from July 2017), with collated information published to the NZClear community for further discussion. We see the visible roadmap path as an integral tool in the continual evolution of NZClear. It will also provide increased collaboration between members prior to acceptance for development. The above proposed changes will be finalised after submissions with the view to incorporating further operating detail in a function overview to be rolled out progressively at the completion of the and Design phase September We welcome your feedback and comments to psr@rbnz.govt.nz by no later than COB Friday 12 May If you have any questions please contact Nathan Lewer on