Q & A - Common for private and corporate customers

• Money order

• I make regular payments via money order to recipients for whom I do not have account information, what should I do?
  If the planned new payment infrastructure will not offer money order, your way of handling / administrating new registrations (your processes) must be changed so that you collect account information for recipients. Alternatively, contact a bank that offers the service money order.
• My customer/counterpart does not want to provide their account number, what should I do?
  In these cases, it will potentially not be possible to send a payment in the planned Nordic payment infrastructure. Contact your bank to see what options are available.
• My customer/counterpart does not have an account, what should I do?
  Encourage your customer to open an account in a Swedish bank. According to current law, all private individuals who are legally residents in the EU have the right to an account in Sweden.
• I make regular payments to recipients for whom I do not have account information by sending a money order (for a first payment, salary, pension, etc.) - what should I do?
  To make a payment in the new planned payments infrastructure, you potentially need an account number. Alternatively discuss with your bank.
• I make regular payments of a single nature (claims settlement, refunds, etc.), what do I need to do?
  You potentially need to either change your handling/administration (your processes) so that an account number is obtained when registering a case in the new planned payments infrastructure. Discuss with your bank how to best make your payments.
• I handle estates (dödsbon) for customers, how do I do in the new planned payments infrastructure?
  Ensure that the deceased's account is not closed until all payments have been received (from the Swedish Tax Agency, insurance companies, pension institutions, etc.). you can also contact your bank to see what options are available.
• What should a recipient for an estate do in the new planned payments infrastructure?
  Do not close the deceased's account until all payments have been received (from the Swedish Tax Agency, insurance companies, pension institutions, etc).
• I will make a payment to an estate (dödsbo), what should I do in the new planned payments infrastructure?
  Normally, the deceased's account will not be closed in the next few months, thus an account deposit should work as usual. Contact the estate (dödsbo) when the account number of the deceased is missing.
• Will I be able to receive a money order in the future?
  It is up to each bank to offer the service if it will not be offered in the planned new payment infrastructure.
• If I receive a money order, where can I redeem it?
  It depends on who issued the money order.

• ERP related questions

• What do the banks need to do? Do they need to hire a lot of developers to develop new services? Or are we as system vendors going to have to carry the big load?
  P27 is developing the platform for the new planned payment infrastructure and those banks deciding to migrate to the new planned payments infrastructure banks need to develop and adapt their systems, products, and services for payments. The adjustments that most banks need to make in their systems are of significant size. We must not forget that today's payment infrastructure has existed for more than 40 years and that its systems have been integrated far into the banks' own systems. Exactly how much you as a system vendor need to do, we do not know exactly. But the perception we have from dialogues in the last 2 years is that it is at least not about very big changes. Hence, our assessment today is that it is not the system vendors who need to do the most.
• Our customers are worried that there will be a big change, can you give them some advice about what they can do already? Or how should they think about this?
  First, I want to say that they should not have to worry. It is natural to feel some anxiety in the face of such a major change, which is the biggest in at least 50 years, however, there is time for preparation. One should, as I mentioned earlier, keep in mind that in the new planned payment infrastructure, file communication takes place directly with the bank and thus it is important to have a file format adapted to the bank. Most banks can already handle ISO formats today and I recommend that your customers have a dialogue with you and their bank about what they can do today to prepare. P27's and Bankgirot's services, at least, during a transitional period will operate in parallel so that the potential transformation to the planned new payment infrastructure can be done in a safe and secure manner. The advice we would like to give is that your customers should listen to their bank and see what their bank will offer in the future. New solutions and opportunities can enable the company's processes to change in a positive direction. Some functions that the company uses today may disappear, and in such case, you need to analyse the impacts. For most people, it will be a quiet journey during the transformation.
• Is there a requirement that the ISO20022 file must contain a bank account number?
  If it is an account-to-account transfer (for example salary) then the answer is YES. A bank account number is NOT needed if it is a payment to a Bankgiro number or a Plusgiro number. In that case, it must contain a Bankgiro number or a Plusgiro number.
• Can you recommend converting ISO20022 files to BGMAX files (or the format you have) as a temporary solution until the infrastructure has "landed"? Is the format (in terms of content) so similar to the existing ones that this is possible?
  If possible, you should avoid converting as there is no 1-to-1 ratio between the different formats. As a temporary solution, however, conversion may be necessary in certain situations. In that case, you should of course do so.
• Can individual banks have their own action plans so that they, for example, deny the current file format earlier than the P27 transformation plan?
  Yes, the date for the transition of the file traffic to the bank is set completely individually by the respective bank. However, all banks that decide to migrate need to adhere to the last date for this.
• For ERI / aggregated payment, will there be a total price or price per incoming payment/reference?
  Contact your bank for information about what the bank offers and the price for this.
• Sealing of pay-out files, will it be a standardized process, or is it up to each bank to choose the way to seal?
  What each bank will offer may vary. Contact your bank for more information.
• What NEW payment products that we do not have today do you see that realistically could arise within P27?
  Only imagination sets the limits. In the short run, it is mostly about the possibility for banks to offer more customized products for their customers compared to today’s products that are of the type “one size fits all”.
• Will all Credit Transfer payments that go into the potential new clearing be settled as real-time payments or will it be like today (x number of settlement opportunities per day)?
  SEK Batch is planned to have 10 possible settlement rounds per day. The main difference is that today's settlement rounds are completely product-oriented, which the potential future settlement rounds will not be. This means that there will be an opportunity to receive large parts of their report early in the day. Exactly what the banks will offer can only be answered by each bank. In the case of SEK Instant, such payments are settled per transaction and in real-time.
• What is the difference between CINV and SCOR?
  SCOR is a reference that must be validated (with a check digit). RF and OCR references are typical ones. CINV is also a structured reference, but it does not need to be validated. It can be, for example, an invoice number.
• It is possible to send a payment with a CINV to a BG number with hard OCR control?
  Yes, unless the bank to which the payment file is sent does not stipulate differently in its MIG.
• It is correctly understood that a SCOR payment can have a Swedish OCR reference or RF reference, but these reference numbers can be structured in different ways? Swedish OCR can have length digit and control digit while RF reference only has control digit, is that correct?
  There is a clear difference between these two types of references. The visible difference is that an RF reference always starts with the letters RF while an OCR reference never has letters. When initiating with a file, the type of SCOR reference stated in the field is specified - which means that the bank knows how to validate it.
• Will RF numbers be supported instead of traditional OCR (in the SCOR field)?
  Yes, unless the bank to which the payment file is sent does not stipulate differently in its MIG.
• Will it not be possible to send structured references, such as scores for an account deposit, due to the new payment infrastructure?
  SCOR can only be an RF reference if it is sent to an account number, i.e, IBAN.
• Regarding reports for payments received to our account, will the format of these files be affected?
  This will highly likely happen. To get knowledge about when it happens and what the alternatives are, you need to contact the respective bank.
• Is it possible for banks not to join the infrastructure and may an ERP provider need to support several formats/standards?
  The banks will choose for themselves whether or not to migrate to the new planned payments infrastructure. According to our knowledge, all banks are currently planning to participate in the new infrastructure. In the new payment infrastructure, ISO20022 will be used (i.e., the same standard). Banks can, however, offer slightly different file communication services, hence contact your bank for more information.
• What will happen with Autogiro?
  Bankgirot will decide the future of Autogiro. The planning of the potential transformation of Autogiro and Bankgiro e-Faktura is in progress. Information will be provided when there is a developed transformation plan for these services.
• Will the payment function Autogiro be available in the new structure?
  In the future payment infrastructure, it is planned for some form of automatic payments with a similar customer experience as the direct debit service. The planning of the transformation of Autogiro and Bankgiro e-Faktura is in progress. Information will be provided when there is a developed transformation plan for these services
• Is it correctly understood that Autogiro, as the product is known today, will disappear and be replaced by Request to Pay due to the new infrastructure?
  Bankgirot will decide the future of Autogiro. The planning of the potential transformation of Autogiro and Bankgiro e-Faktura is in progress. Information will be provided when there is a developed transformation plan for these services.
• Does ERI require an aggregated payment?
  Yes, ERI is a term used for a payment with several underlying references and amounts, an aggregated payment.
• How does the recipient receive information about which invoices/credit notes the payment refers to if the payment contains more than 15 references?
  ERI makes it possible to have up to 999 references. If the recipient bank offers ERI, it will be reported in the way the recipient bank offers.
• Does the OCR control work even if the user sends multiple invoices via ERI? And then specifies that two of the invoices are credit and one is debit?
  Yes,
• Can the banks, for example, debit union fees for SALA payment (as done today)?
  What each bank will offer may vary. Contact your bank for more information.
• Will senders be able to choose whether payments initiated in a file should be booked in bulk or booked individually?
  In general, there is that possibility. However, what each bank will offer may vary. Contact your bank for more information.
• What are the differences in the handling of the payment types: SALA, PENS, and SSBE?
  In general, there is no difference between these three "Category Purpose Codes". However, they differ from other account to account transfers because they are credited to the recipient's account at 00:01.
• Can there be several payments with the same recipient, reference, and amount in the same file?
  Yes, unless the bank to which the payment file is sent does not stipulate differently in its MIG.
• Today, we use BG payments and Autogiro payments, which we have chosen to collect in one report and in the same file daily for all our customers. Our customers have all optional banks, and this function is available through Bankgirot today. Will there be corresponding mass handling functions at the banks in the new planned payments infrastructure?
  No, the reports will be handled by each bank. Depending on what this looks like and what each bank offers, there may be opportunities to "merge it" at a later stage.
• How does the sender of a payment send a structured payment with CINV, does the sender himself fill in a field in a banking system? I ask because in a receiving system of payment we want to know how secure that reference is when we allocate the payment.
  It differs a little depending on how the payer initiates this. If the payer initiates the payment by submitting a payment file in the PAIN format, the payer sets the CINV parameter himself. If the payer initiates the payment via one of the bank's digital channels, the parameter is set by the bank - in these cases it cannot be assumed that there will be a structured reference with the parameter CINV.
• How exactly must the payee's name match the payment orders? Spelling, abbreviated company names, etc.?
  There will not be any controls of spelling or similar.
• Will mobile phone numbers also be released as aliases for more general use than Swish only?
  It remains to see. At least there is nothing that makes this impossible in the new payment infrastructure.
• What are NPC Schemes?
  NPC has currently published two regulations; NPC Credit Transfer Scheme (published in December 2019) and NPC Instant Credit Transfer Scheme (published in February 2020). These regulations are sets of rules, methods, and format descriptions to achieve interoperability for bank-to-bank transfers for Swedish and Danish kronor, either as so-called batch payments or real-time payments. The regulations are written on a conceptual level and to these are various implementation guides and recommendations linked. The regulations are based on, and are very similar to, the regulations for payments that the European Payments Council (EPC) provides for Euros within the Single Euro Payment Area (SEPA) and the message format ISO20022.
• What distinctions from the SEPA standard have been decided?
  Banks and payment institutions can join one or both currencies (Swedish kronor, SEK, and Danish kroner, DKK) and one or more schemes. Banks and payment institutions can choose whether they intend to receive cross-border payments. In addition to IBAN, which defines a recipient account, an Alias / Proxy can also be used by the customer and will in these cases be forwarded to the recipient bank in a new separate attribute (AT-25). The new Nordic regulations make it possible to send payments with ERI (Extended Remitted Information) and payments without ERI in the same file. This applies to the banks that have chosen to accept ERI and offer services that make it possible. The underlying amounts in an ERI payment will be validated against the total amount of the payment message. An ERI payment can include credit invoices – the total amount must exceed SEK 0.00. Mandatory validation of the structured references OCR and RF references. The set of characters allows Scandinavian characters and @. Amounts can be up to 11 digits (9 digits for SEPA payments). Some differences in the use of Local Instrument, Charge Bearer, and Service Level.

Senast uppdaterad: 2022-08-15