21 Jan 2022

What changes will take place in the iFOBS remote banking system during the transition to the new SEP-4 standard? Should the new payment format with the symbolic "pain.001" name become a headache for the client? What has been done so far and what is planned? The analysts from the Front Office Systems Department at CS ltd are answering the above-mentioned and other questions.

How will the standard payment order in national currency change?

The main entity that clients work with in iFOBS is a payment order in national currency. Now for the client convenience it contains the minimum number of details to fill in. In the future, according to the requirements of the new pain.001 payment format, the client payment form will have an extended set of fields to be filled in. First, it is the Payment purpose and the details of Payer and Recipient.
Therefore:

• the payment order in the national currency will be expanded with the required set of fields to be filled in for compatibility with the new pain.001 format.

Should pain.001 become a headache for the client?

This is one of the first questions we’ve asked ourselves. Should all the new standard innovations of electronic payments in Ukraine between banks and agents become a headache for the client?
We don’t want to make things difficult for a client. We would like to leave the form of payment in the national currency the way it is now – small (fits on one screen) and familiar for clients. Unfortunately, the changes should be made, so we are planning to make them as painless for the client as possible. 

What exactly is planned to be done in terms of sending the payment under the SEP-4?

The new form of payment in the national currency looks like SWIFT payment form, but we want to make it smaller than SWIFT and, at first glance, this task looks quite possible.
Nevertheless, we must expand the "Payment purpose" field with a structured block for entering new data. This has already been done in our test version. The same structuring will apply to the tax payment details – in this part, we also work with specialists from the regulator and the State Tax Administration of Ukraine, and we will have to take into account the latest changes reflected in the pain.001 version.
We also have to take into account the extensions proposed by the new standard in the details of the Payer and Recipient – and we have already increased the size of the fields with the name of the Payer and Recipient. Subsequently, in this part, we are planning to consider the possibility of dividing into the actual payer and recipient, and into actual ones, as the pain.001 suggests.
However, we do not want the client to take all requirements in filling out the payment form as pain.001. For example, we would like to restrict ourselves to implementing the payment import format as pain.001. So, if the client's accounting system can export the payments created in it to the pain.001 format, then the iFOBS system will be able to import them in the same format (at least large import accounting ERP systems can perform such exports).
Thus, as for the payments sending in SEP-4 there will be the following changes:

• the "Payment purpose" field will be expanded and subsequently structured on all forms of creating, viewing and editing documents in hryvnia, lists of payments and templates;
• the details of the Payer will be expanded;
• the details of the Recipient will be expanded;
• the ability to import documents in pain.001 format will be added.

What about new roles in the chain of payments sending and receiving?

In the new format, in addition to the usual Payer and Recipient, additional possible participants appear on both sides – the Payment initiator, Payer and Actual payer, the Recipient and Actual recipient, intermediary agents (Agent 1, Agent 2, etc.).
We decided that at the moment we equate all the roles and leave the clients as they were: there is only one Payer who wants to pay, and there is one Recipient who wants to receive. So, the Payment initiator, Payer and Actual payer are the "Payer", the Recipient and Actual recipient are the "Recipient".
As for intermediary agents, the presence of which provides for the pain.001. As experience shows, a client who now, and in the near future, needs to make a hryvnia payment within Ukraine, is unlikely need to instruct they bank to put this payment through a network of intermediaries.
Subsequently, if there is a need to expand the network of agents, we will return to this issue and implement what the client specifically needs.
In total, at this stage: 

• all participants in payment sending are equated to a "Payer" single role;
• all participants in the payment receipt are equated to a "Recipient" single role;
• the payer's bank will directly transfer the payment to the beneficiary's bank, without agents.

What is planned to be done as for the payment receiving from SEP-4?

Of course, in addition to the "Pay" function, the remote banking system has a "Receive" function. In this regard, iFOBS will standardly, as before, collect payments made from Documents of the Day in the CBS. That is, as before, all transactions will come from the CBS to iFOBS, the client will see their outgoing and incoming payments, build on their basis a printed statement form, which is familiar to both clients and accounting department.
If the bank uses B2 CBS, in addition to the existing data structure, iFOBS will be able to download its XML structure from B2 for each transaction – this is part of the pacs from SEP-4 which entered the bank. With the help of this XML structure, we plan to implement the second part within the framework of the new standard at the client site, which directly refers to the client requests to the remote banking system, namely, it will allow to upload a statement in the camt.053 format.
Such an upload, again, will be performed as an export file for further uploading to the client's accounting system, if this accounting system can import account entries (statement) in the camt.053 format.
That is, in terms of receiving payments from SEP-4, the following is planned:

• receiving a statement in the camt.053 format;
• ability to request selectively an XML file for an incoming payment in B2 CBS.

Where are we now and what are the future plans?

With the emergence of the first news about the new ISO 20022 standard introduction and the transition to SEP-4, we started at once and continue to conduct analytical work.
We have studied the interim data from the regulator (when the first, partially developed pain.001 formats were provided), participated in workshops, in discussions and followed the explanatory work of the regulator.
Since we had had already developed formats (at the moment, the pain.001 format dated October 1, 2021, is considered to be finalized), we began to deploy a separate test line of servers for developing and testing new outgoing and incoming payments to be able to check during development the payments transferring from the client via the CBS to the new SEP and back to the client. 
There is already certain planned version for iFOBS release - 21.8.0.X.
Total for today:

• a preliminary analysis of the requirements for the new format was carried out;
• at the moment, the deploying a separate line of iFOBS test servers is in the process;
• the nearest plans include connecting the iFOBS 21.8.0.X version to the NBU SEP-4 test bench (via B2).

What about the new ISO 20022 tools implementation: payment recall and others?

Indeed, the new standard provides special formats for initiating such requests and notifications of such requests’ execution, but for now we are acting within the framework of what iFOBS can provide at the moment.
Of course, we are ready to expand the number of entities in iFOBS. For example, now, in addition to payments, it is possible to create information debit documents (“invoices”) and payrolls.
 If there is an expansion of the system functionality with such entities as payment recall request, then, of course, under the conditions of the new standard, the addition of these entities is followed by meeting the requirements for formats.

What is expected on August 20, 2022?

As a result, we have the following date: August 20, 2022, and the following task set by the regulator and the market: to ensure sending payments, receiving payments and statements in new formats.
So, if the new generation of SEP starts working from August 20, 2022, we will also have to provide our customers with sending payments through all channels of the iFOBS remote banking: web client, win client, mobile clients, open interfaces. 
All above-mentioned is in our work plan, and we will provide it by the specified date to the above-mentioned extent. And for the next step, the market will assist, and both the regulator and clients themselves will help.