FAQ on SEPA

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Insights
 
 
 
 

This section shows a series of FAQ regarding Sepa migration.

It is also available below to download a document summarizing a further set of questions (and answers) collected as part of webinair SEPA organized by CBI.

 

 
General information
 
SEPA Direct Debit collections area
 
SEDA Collections Area (SEPA Electronica Database Alignment)
 
SCT Payments Area (SEPA CreditTransfer)
 
 

General information

This paragraph provides answers to the most frequently-asked questions received from CBI clients in relation to the SEPA end date, with a particular focus on the activities of CBI S.c.p.a.

 
1. Does the SEPA end date of 1 February relate to both PSP and USP?

CBI recommends that this question be addressed to the competent offices of the ABI or to your bank.

 

  Focus on CBI

 

1 February 2014 was the date of the SEPA migration of interbank procedures  in relation to: retail credit transfers (BON), ordinary and express direct debits.

 

With regard to CBI operations, from 1 February 2014, CBI clients will only have the following options:

 

a) immediate use of the CBI SEPA XML record layouts (seethe latest manuals published on the consortium's website in the Upcoming releases area). The Consortium strongly recommends this solution, which allows adaptation to the Regulations and avoids a dual impact on business processes and systems.

 

b) use of porting record layouts (seethe latest manuals on the Consortium's website) with the aim of giving SEPA instructions based on conversion agreements with the reference banks. This option will be accessible until 1 February 2016, when clients will also have to adapt to XML.

 

In any case, regardless of the decision (porting or native XML), urgent action must be taken to adapt record layouts, with particular regard to the maintenance of active direct debits, which must be transposed to SDD procedures from 1 February.

 

All the manuals required with regard to CBI operations are available in the relevant sections of the CBI website.

 
 
2. In order to use the SEPA conversion services, will it be enough to use the new versions of the porting record layouts?

To facilitate the conversion of existing "PORTING" services to the new XML SEPAcompliant services in the transition phase from February 2014-January 2016, CBI has incorporated new information into the Porting function manuals (BON, R.I.D. and A.E.A.). In most cases this new information has been defined as optional.

 

The use of these record layouts to provide SEPA instructions must be agreed between the customer and the bank offering the conversion service (in the competitive environment the service can be offered either by the Access Bank or by the Executing Bank).

 

The new fields, particularly in the CBI-RID and CBI-AEA, have been made optional with the sole purpose of avoiding interference with the client-bank relationship in the competitive arena. However the information transmitted in these fields is necessary for euro-denominated presentations, which must be settled through the SEPA channel (in particular SDD and SEDA).

 

For this reason, it is essential for clients to agree how transcoding is to be carried out before sending Porting flows to be converted into SEPA instructions.

 

  • The 15 EU countries that use the euro (Italy, Germany, France, Spain, Portugal, Greece, Austria, Finland, Ireland, the Netherlands, Belgium, Luxembourg, Slovenia, Cyprus and Malta);
  • the 12 EU countries that do not use the euro nationally, but make payments in that currency (the UK, Sweden, Denmark, Estonia, Latvia, Lithuania, Poland, the Czech Republic, Slovakia, Hungary, Bulgaria and Romania);
  • Another 4 countries: Switzerland, Norway, Iceland and Liechtenstein.
 
 
3. Will the BIC code be required after the end date?

It will only be obligatory after the end date for CBI cross-border operations, and only until February 2016. CBI recommends that this question be addressed to the competent offices of the ABI or to your bank.

 
 
4. Where Porting record layouts are used to give SEPA instructions, in what format will the return flows be produced?

The guiding principles laid down by CBI require that the workflow be respected. If the client uses fixed record layouts, the advices and corresponding returns must be received in the fixed record format.

 

However, depending on decisions in the competitive arena, both the xml andporting formats may be transmitted to the client. Naturally, this can only happen if the Access Bank carries out conversion services for the client in question.

 

For this reason CBI suggests that this query be addressed to your bank.

 
 
5. Does the Consorzio CBI offer validation services for porting and xml record layouts?

Currently, CBI is unable to offer a centralized function for the checking of files or simulation of exchanges, as these functions are the responsibility of the individual consortium members/payment service providers.

 

However, to assist clients in structuring the xml formats, the "Standards" section of the consortium's website includes a user guide (STUS-MO-001).

 
 
6. Are the SCT and SDD CBI xml standards ISO- compliant?

The standards for the new CBI services derive from the Customer-to-Bank ISO20022 standard and are applied in the specific context of each service. By way of example, the CBI specifications for the XML SEPA credit transfer (version 00.04.00) are based on ISO20022 message pain.001.001.03 and are compliant with the SEPA Rulebook. As mentioned, the message pain.001.001.03 is not used in full, since it is structured in a way that is applicable to a very wide range of cases and parties.

 

In order to implement the community rules, the CBI SEPA Credit Transfer CBI record layout should be a subset of the above ISO message. It contains the information required to make a credit transfer in Italy, such as the mandatory ABI code of the debtor agent in the “MmbId” field (this is optional in the ISO record layout).

 

The CBI Standards are thus ISO  compliant .

 
 
7. Does the CBI provide ISO-compliant guidelines for conversion to foreign formats?

CBI is unable to provide guidelines of this type.

 
 
8. The new CBI xml standards require the CUC code - is this data essential for settlement through the SEPA channel?

The CUC code is the unique CBI code that identifies all the parties in the CBI community (clients, banks and network access points).  It is different from the SIA code, but is linked to it as there is a one-to-one correspondence in the CBI Directory, which is the central point of reference that is also used to address messages in the CBI network.

 

The CUC code is only used to identify the senderand not for settlement on the SEPA channel.

 

The CBI sender, used to inputting the SIA code, is certainly already matched to the CUC (which is in the client-bank contract documentation). It is an 8-digit alphanumeric code, which is automatically allocated by the access bank when the CBI contract is signed.

 

The CUC code is assigned by the Access Bank if the client is operating within CBI circuit with a multi bank approach. If the client wants to operate with a single bank approach.outside the CBI net (eg within a bank closed circuit), the client can still fill CUC field with a fake CUC code, SIA Code (eventually with 3 zero ahead or "SIA"+siacode) or another code agreed with the bank. In this case CBI banks don't have to take a census of the client on the CBI Directory, except for particular cases (eg. end-to-end documental services).

 
 
9. With regard to client messages, does the logical message have to be elaborated, or the whole physical message?

The CBI user has to elaborate the logical message. In order to be transmitted on the CBI network, this message must be accompanied by two headers, the structure of which can be found in the CBI function manuals. However, these headers only relate to the banks (for further information, see the STUS-MO-001 document on the Consortium website www.cbi-org.eu , in the Technical Standards area).

 
 
10. Can xml files be structured with several Group Headers?

The Group Header is always unique, according to the identification generated by the company. On the CBI network, the receiving bank (the Executing Bank)  for example the Debtor Agent of the SCT and the Creditor Agent of the SDD) is always unique, for structural reasons. In the case of SDD, there are also multiple blocks of payment information, so that different due dates can be managed in the same record, and so that there can be no change to the Initiating Bank, which is always unique.

 

However, in the competitive environment clients can check with the access bank as to whether it is possible to generate a single xml file with several records, therefore group headers.

 

For this reason CBI suggests that this query be addressed to your bank.

 
 
11. Are there community rules for defining the namespaces of the CBI xml files?

With regard to clients' generation of xml files to be imported on the corporate banking front-ends, we recommend that customised namespaces are not used – in other words only the default CBI definitions should be used.

 

By way of example, there are two acceptable cases of xml presentations, relating only to the SCT function with correctly compiled namespaces:

 

No customised namespace (recommended option)
No customised namespace (recommended option)
 
 
Namespace defined according to the CBI naming convention (PMRQ in the case of SCT)
Namespace defined according to the CBI naming convention (PMRQ in the case of SCT)
 

The definition ofnamespaceson the client side imposes no restrictions on their maintenance nor on the Access Bank (except for imported flows containing digital signatures) for flows subsequently transmitted for CBI operations, nor on the Executing Bank for the return flows (advices).

 
 
12. How should the FwdgAgt block be used on the SCT CBI xml files?

The FwdgAgt is only used (and is obligatory) in the case of requests from the Marketplace, as in this case the return flows must be returned not to the Access Bank associated with the client but to the Gateway bank operating in the marketplace, so that it can make them available on the same portal instead of on the client's corporate banking station. The client will obviously receive the operation on the debtor account through the reporting flows.

 

The Gateway Bank is different from the normal operations of the Access Bank, and is the only case in which the sending bank needs to be reported in the transfer flows, in exactly the same way as the method used with current PC-EF transfers.

 
 
13. Currency communications relating to operations in San Marino, following entry in the SEPA area, are obligatory?

Where the IBAN is based in San Marino, currency communications (CVS) are only obligatory until 30 March 2014.

 

From 31 March 2014  the fields relating to currency communications (CVSwill become optional for all the cross-border functions involved (see the manuals in force from 31 March 2014).

Also note that the counterparty's BIC code for SCT/SDD operations to San Marino will no longer be required from the same date, according to decisions taken by ABI on the derivation from IBAN SM (as for IT).

 
 
14. Do the CBI xml flows allow special characters such as "&" in the tags on the company name?

In Customer to Bank operations, in terms of the CBI standard, all the basic Latin characters are permitted in line with the EPC guidelines.

 

However, we recommend that users consult the "General rules and criteria" manual for the new STPG-MO-001 services, which is available on the website of CBI. Paragraph  11.9 of the manual, "Permitted characters") contains the following rule, which is in full accord with the official EPC guidelines:

The use of additional characters entitles the receiving bank to refuse the message or to convert these characters as described in the EPC217-08 SEPA Conversion Table.

 

Instead of imposing a strict limitation on the set of basic Latin characters, a more flexible rule has been introduced, although it is linked to multilateral agreements as it is a pan-European model. The general recommendation is the one given above, in other words to use the basic Latin set for the moment (or convert at origin according to the Conversion Table), because otherwise there is a right of rejection and therefore a bank/PSP or clearing platform (CSM) could reject the payment, at least until the use of additional commonly-used characters such as "&" or "@" is fully harmonised – the CBI usually permits these characters but obviously cannot guarantee that there will be end-to-end coverage on all transactions outside of its own remit. The recommendation to use minimal characters also applies in consideration of the fact that – for precisely the above reasons – the inclusion of other characters could lead to manual re-inputting, and thus to delays or impediments.

The ultimate objective is to extend the basic set of SEPA characters as soon as possible, provided that it is accepted by the reference CSMs (e.g. EBA) and where possible by the EPC. Updates will follow as necessary.

 
 
15. The Porting manuals permit more characters than the xml manuals. What happens in the case of conversion to

The PORTING character set is larger than that of the new SEPA-compliant XML services using UTF-8 (Latin script). In the case of conversions (e.g.: €, &, @), incompatible characters should be dealt with using the EPC217-08 SEPA Conversion Table.

 

In any event, we recommend contacting the bank carrying out the conversion service.

 
 
16. The CUC code does not allow lower-case characters. Does this mean that the entire flow could be rejected?

As is the case for the current porting flows, where the SIA codes in lower-case are usually rejected, we recommend that CUC codes with lower-case letters should be avoided, as the code is case-sensitive and therefore lower-case letter would usually be interpreted as a different character and could lead to rejection by CBI transmitters.

 
 

SEPA Direct Debit collections area

This paragraph contains replies to the most frequently-asked questions received from CBI customers in relation to the xml SDD function and the fixed-record direct debit function, with which customers can order SDDs until 1 February 2016.

 
1. How will the continuity of existing direct debits be guaranteed?

The Consorzio CBI recommends that this question be addressed to the competent offices of the ABI or to your bank.

 
 
2. In case of RID collections with "due date" beyond 31st January 2014, is it guaranteed the RID mandate continuity?

The Consorzio CBI recommends that this question be addressed to the competent offices of the ABI or to your bank.

 
 
3. How can clients tell their banks that they want to convert a Porting flow into an SDD order?

First of all, an agreement is needed between the client and the bank. From an operational viewpoint, record 17 must be used, in all the instructions on the record.

 

Note thatit is not possible to generate records with mixed instructions, some with the 17 record and others without.

 
 
4. In case of migration to SDD mandates, it could be difficult to recall the "date of signature". Should it be used a default value?

CBI suggests that this query be addressed to your bank.

 
 
5. Will it be possible to utilise the SDD service without joining SEDA?

CBI recommends that this question be addressed to the competent offices of the ABI or to your bank.

 
 
6. What does "sequence type" means? In case of data conversion from legacy format, is it mandatory?

CBI recommends that this question be addressed to the competent offices of the ABI or to your bank.

 
 
7. In the case of conversion, can the creditor identifier field in the porting record layout be left empty?

CBI suggests that this query be addressed to your bank.

 
 
8. With regard to RID record type 17, if the customer does not insert the IBAN code, is it accepted for data conversion to SDD?

Record 17 indicates presentations to be settled through the SEPA channel regardless of whether or not the fields have been completed. This should be agreed in the contract between the client and banks offering conversion services on a competitive basis.

 

The IBAN, as with all supplementary SEPA data, is optional, but it is strongly recommended that this field be compiled as it is required by the SEPA model. The bilateral agreements mentioned above should confirm this, as their aim is to govern the conversion services.

 

For this reason the Consorzio CBI suggests that this query be addressed to your bank.

 
 
9. In the case of conversion, is it possible to use the direct debit cancellation function?

As direct debit cancellations have no equivalent in the SDD model, they have been excluded from conversion services and therefore do not apply to SDD flows which are characterised by record 17.

 

CBI suggests that this query be addressed to your bank.

 
 
10. In the case of conversion, how will the mandate be identified, as there is no corresponding field in the record layout?

Users who have not transitioned immediately to xml will be able to use the existing direct debits (and AEA); the new identification has not been included on these. It can occupy up to 35 characters but for the sake of continuity only the "triplet" has been left (pos. 92-113 record 10 direct debit record layout which is the only ID - of 22 characters – which is handled by creditors if they have not already migrated). The triplet will then be transferred to the Mandate ID field of the SDD presentation according to ABI rules. As this field contains 35 characters it will hold it quite comfortably.

 

 

CBI suggests that this query be addressed to your bank.

 
 
11. In case of CBI XML credit transfer to legal entities, is it mandatory to valorize the tax code?

In the BON PC-EF record layout, the tax code of the "legal entity creditor" is optional and can be completed in the specific case.  Credit transfers to legal entities can also be managed if the CBI SEPA xml Credit Transfer format is used.

 

With reference to the STIP-MO-001 manual, the 2.12.8.3 identifies the counterparty – including the fiscal counterparty – and is optional.

 
 
12. In case of financial and fixed amount RID, not involved in SEPA end date, is it allowed to use the CBI SCT XML?

We can confirm that a creditor company collecting financial or fixed-amount direct debits can collect them through the national direct debit procedure until 1 February 2016 (as "niche" products) or alternatively, they can be collected through the SEPA Direct Debit model (Core or B2B).

 

However, if the creditor decides to:

 

  • continue using the direct debit service(financial/fixed amount), the collection flows can be presented using the standard non-enhanced CBI director bit flows, but in general there are no changes compared to the current system;

 

  • handle debit authorisations for the financial/fixed amount of direct debits through SEPA Direct Debit, the collection flows can be presented using the CBI file for the SDD service in XML format, or alternatively the IR-EF format (the enhanced record layouts that enable the presentation of SDDs in non XML format).

It should be noted that after the dispatch of a SEPA DD referring to the authorisation for the debiting of a financial/fixed amount direct debit,the PSPs will automatically migrate these authorisations to SEPA. From that time, the charges can only be managed on the SEPA DD model(in other words the creditor company cannot send direct debits on some occasions, and SEPA Direct Debits on others). For the migration of a financial/fixed amount direct debit authorisation to the SEPA DD model, these charges will be handled in accordance with the rules of the SDD model (for example, the deadline for the submission of a refund request by the payer, regardless of the terms stipulated in the direct debit authorisation, will be 8 weeks for an SDD Core, with no possibility of refund in the case of an SDD B2B).

 

Finally, with specific reference to the possibility of a company presenting requests for direct debits (financial or fixed amount) and requests for SDD debits in a single CBI file, this option is not available as the files are separate in terms of structure and information (one for SDD presentations in XML format and one for SDD presentations in non-xml format).

 

For full information about the above points, refer to your bank and/or the applicable ABI regulations.

 
 
13. The identification fields for the creditor and debtor (tags 2.6.3 and 2.13.8.3) are optional. If these tags are not set, are the creditor and debtor identified from their IBANs alone?

The aforementioned identification codes for the creditor and debtor are optional. However, the identification code for the creditor according to EPC rules in the block <CdtrSchmeld> (tag 2.12.3), now also known as the CID (Creditor Identifier), is mandatory. In general, it is mandatory to indicate just the name, in descriptive form, for tags 2.6.3 and 2.13.8.3.

 
 
14. Is it possible to import the outcome of a SEPA instruction sent to the bank into the company management system? What is the structure for doing this?

Just as in the past for direct debits, the creditor's bank returns an outcome (only negative = rejection or unpaid), based on the corresponding new format XML StatusReport, which is available in the Technical Standards section of the consortium's website www.cbi-org.eu (Collections Area). Access requires registration as a "non-member" user and is completely free of charge.

 
 

SEDA Collections Area (SEPA Electronica Database Alignment)

This paragraph answers the most frequently-asked questions received from CBI clients in relation to the xml AOS SEDA function and the fixed-record AEA function, with which clients can transmit SEDA alignment messages.

 
1. The data added to the AEA record layout also includes the "mandate type", the permitted values, and their meaning?

The field indicated should only be used in the case of a SEDA alignment request. It identifies the type of mandate and, if present, it must have one of the following values:

 

·         CORSEDPM;

·         CORSEDEM;

·         COR1SEDPM;

·         COR1SEDEM;

·         B2BSEDPM;

·         B2BSEDEM.

 

This attribute indicates the mode of acquisition (hard copy or digital copy) of the SDD mandate to be aligned:

 

·         CORSEDPM: core mandate – hard copy;

·         CORSEDEM: core mandate – digital;

·         COR1SEDPM: core1 mandate – hard copy;

·         COR1SEDEM: core1 mandate – digital;

·         B2BSEDPM: B2B mandate – hard copy;

·         B2BSEDEM: B2B mandate – digital.

 

Note that the "Core1" codes can be assimilated to the "Core" code.

 
 
2. Will the use of record XX in the AEA record layout be obligatory from 1 February 2014?

Use of the XX record type is only linked to the use of conversion services to and from SEDA. This service requires subscription to the SEDA models.

 

The AEA function will not be discontinued after 1 February 2014 and may be used without the XX record for the electronic alignment of files referring to niche direct debit mandates.

 
 
3. How can clients tell their banks that they want to convert a Porting flow into SEDA messages?

First of all, an agreement is needed between the client and the bank. From an operational viewpoint, record XX must be used in all the instructions on the slip, to indicate SEDA instructions.

 

Note that it is not possible to generate records with mixed instructions, some with the XX record and others without.

 
 
4. Does the CVS communication still have to be given on the SCT slip?

The CVS communication, previously mandatory for non-Italian IBANs, was made optional from 31 March 2014 for all affected cross-border CBI functions.

 
 

SCT Payments Area (SEPA CreditTransfer)

This paragraph answers the most frequently-asked questions received from CBI clients in relation to the xml SCT function and the fixed-record BON function, with which customers can order SCTs until 1 February 2016.

 
1. Will it be possible to use all the traditional banking reasons, by using the porting record layout to order SCTs?

CBI suggests that this query be addressed to your bank.

 
 
2. Can the PC-EF porting record layout also be used to order euro-denominated SCTs to foreign countries in the SEPA area?

CBI suggests that this query be addressed to your bank.

 
 
3. The "Identifier for a payment instruction" block contains the tag " Unique identifier assigned to the instruction by the Initiating Party in relation to its Bank" and " URI identifier assigned by the Initiating Party ". What is the difference between t

The Instruction Id is the one assigned by the company to an individual credit transfer on the slip.  It equates to the existing "progressive slip number" on the CBI-BON-001, and is of a lower level than the Message Id (= support name for the existing flows).

 

Unlike the existing identification on the BON, the Instruction Id has an unstructured form and does not necessarily have to be structured as a progressive number, depending on the criteria defined by the user's ERP application.

 

The end-to-end Identification is used for reconciliation purposes and is included by the sender in order to facilitate the reconciliation process on the creditor's side. It represents the Unique Remittance Identifier (URI) and may be a unique code and/or number of the invoice or other trade document.

 

CBI suggests that this query be addressed to your bank.

 
 
4. Does the CVS communication still have to be given on the SCT slip?

It is still obligatory on cross-border CBI flows but will shortly be reviewed. The Consorzio CBI suggests that this query be addressed to the reference bank.

 
 
5. Will it be possible to manage the execution date and value date with SCT?

The SCT record layout does not manage the value date. The ISO standards and European standards eliminated the concept of a predetermined value date some time ago, as it has been assimilated to the date of settlement.

CBI suggests that this query be addressed to your bank.

 
 
6. Will it be possible to handle different execution dates in a single SCT file?

Each slip can contain a single date of execution for structural syntax reasons. The possibility of aggregating two different slips in a single physical file must be verified with your bank.

 

For this reason the Consorzio CBI suggests that this query be addressed to your bank.

 
 
7. In the case of conversion, from 1 February will it be obligatory to indicate the IBAN on SCT instructions given with the PC-EF layout?

From 1 February, only the IBAN will be permitted in all credit transfer instructions (except for cheque issue requests).

 

CBI suggests that this query be addressed to your bank.

 
 
8. With regard to the RgltryRptg tag (2:12:13), is it mandatory only in case of "not IT creditor IBAN"?

It is correct that the "Details" in the Regulatory Reporting block (2.12.13) are optional, however in certain cases the receiving bank may carry out additional material checks, which are not governed by the Consorzio CBI, and the Consortium has no discretion in this regard.

 

For this reason the Consorzio CBI suggests that this query be addressed to your bank.

 

From 31 March, the Regulatory Reporting block will be completely optional for all the cross-border functions (SCT, SDD, foreign PE-EF credit transfers) as the underlying regulations are being eliminated in order to align with the harmonisation process currently underway in Europe.

 
 
9. In the xml SCT record layout, how will the advices be managed, i.e. transfer completed, not completed or cancelled (68000)?

The individual transactions on the SCT Status Report will show "ACSC", which equates to completed, or "RJCT", which equates to rejected, and the rejection will be accompanied by the various ISO reasons.  Cancellation (re-accrediting after debiting) does not have a unique reason in native SCT, as the codes indicating cancellation may be linked to various status reasons such as:

AC03
InvalidCreditorAccountNumber
AC06
BlockedAccount
AC07
ClosedCreditorAccountNumber
 
 
 
10. In the SCT environment, is the CUC obligatory?

The CUC code is required for operations on the CBI multibank circuit (it can be found in the Initiating Party field = Flows sender, first occurrence).

 

In the competitive environment (e.g. single bank), institutions can make it easier for clients with no CUC by treating this field differently. For more information, ask for clarification from your Bank / PSP.

 
 
11. Does the CBI SCT record layout conform to the ISO XML CustomerCreditTransferInitiationV03 layout?

This question is answered in the general section of these FAQ. With regard to the CBI SCT record layout in force on 31 March 2014, the CBI uses its own CustomerCreditTransferInitiationV03 standard, published by ISO20022 (ISO, see www.iso20022.org). The current ISO versions are always shown in the revision tables of all new services (fields' Excel files).

The only "non ISO" tag that is obligatory within the CBI - at the specific request of the member banks - is the "tag root", which was not initially part of the ISO documentation. It is also easy to manage, as in the competitive environment the PSPs can facilitate users by converting the ISO tag root (destined for multiple applications) into the CBI SCT tag.

 
 
12. What does the value "HIGH" for the tag Instruction Priority mean? Does it identify an instruction of an urgent nature?

The new version SCT CBI 00.04.00, in effect from 2 March 2015 contains a harmonised indication of the meaning of "HIGH" priority, according to which that flag allows the user to request the "same-day" accrediting of funds, on the basis of specific bank-customer agreements. Otherwise, from the same date, on an optional basis the new XML Urgent Credit Transfer function (distinct from the SCT function) will allow payments to be executed as urgent transactions through a settlement system outside the ordinary SEPA channel.

 
 
13. What is meant by "cumulative debit"? When must the batch booking tag be used?

A cumulative debit is simply the debiting in a single accounting entry of all credit transfers included in the slip, e.g. the salaries slip debited for all individual credit transfers. On the subject of batch booking, it is also specified that "In the absence of specific bilateral agreements on the use of this field, the input of a value by the customer does not oblige the debtor agent to apply the booking requested."

 
 
14. Despite being an optional field, can the country of residence (creditor/debtor/ultimate creditor) also be set for legal entities?

We confirm that the CBI standard permits it. In cases of legal entities, the country of residence is the same as the registered office.

 
 
15. Despite being an optional field, when must the "Purpose" tag (purpose of the end-to-end transaction, tag 2.12.12) be used?

Since this is end-to-end information, it relates solely to end customers' needs.

 
 
16. Who are the parties involved in an SCT instruction?

In SCT, as opposed to current credit transfers, there are three different parties involved, in a structured manner, on the ordering party end:

  • Initiating Party: this is the company that orders the flows, or that sends them physically, as authorised to draw on a given company account;
  • Debtor: this is the company that holds the account; it normally coincides with the Initiating Party, except in cases of management "in the name and on the account";
  • Ultimate Debtor: this is the company/person to which/whom the invoice is addressed, i.e. the actual debtor, known only to the Initiating Party/Debtor. This information, if included, is required to be sent to the beneficiary bank and the Debtor, and according to the CBI record may contain the name, address and an identification code (which may be a tax identification code).

 

Then there are two different parties on the beneficiary's end:

  • Creditor: this is the individual/legal entity that holds the account to be credited
  • Ultimate Creditor: this is the individual/legal entity that issued the invoice, i.e. the actual creditor in the relationship underlying the transaction.
 
 
 
 
 
 
 
 

CBI S.c.p.a. - Fiscal Code 97249640588

R.E.A. N. 1205568 - Registered Capital 920.474 euro i.v. - VAT Identification  08992631005