SEPA Initiator Identifier

In SPAIN when generating a SEPA file for payment ordering the initiator identifier must be diferent than the sepa creditor identifier. This is explained on page 33 of the normative, which I copy paste here:

En Identificación, salvo acuerdo previo entre el ordenante y su entidad financiera, se
aplicará la siguiente regla de uso de la comunidad española. Es obligatorio que el
ordenante consigne el NIF-Sufijo (12 caracteres) cuyo uso tenga acordado con su entidad

I’m wondering if there are other european countries with similar need and how are you manging this cases.

I do not see in the quote the requirement about having two different identifier.

Sorry, I did not add the link to show how the sepa creditor identifier is composed on Spain

But as resume, sepa creditor identifier is build as:


Where DD is the digit the control, XXX is the sufix (normally 000) and ZZZZZZZZ is the vat number of the company

And sepa initiator identifier is build as:


Where ZZZZZZZZZ is the vat number and XXX the sufix.

So you mean that for debit like PAIN.001.003.03 the <PrvtId> should not be SEPA but something but the NIF.
I made some research and in Belgium we must put the enterprise number as <Id> and “KBO-BCE” as <Issr> (ref: Standard Credit Tranfer page 23).
What are the data for Spain?

So I think we should update the PAIN template to use another identifier than the SEPA and have some code that each country must implement to find the proper ID.

Yes, nif plus 3 extra digits (normally 000)

In Spain Issr is Optional. One of: Cd, Prty or Issr should be specified, so it works with the current Prty

For me, it looks strange that two different “number” have the same schema name.
Any way, my proposal is still valid:

I’ve just created Issue 8063: Add sepa initiator identifier - Tryton issue tracker

Where does the suffix comes? How does the company knows it?

The company is free to choose the suffix.

Here are some criterias used to choose the suffix:

El sufijo es el código comercial del acreedor y se utiliza para identificar diferentes líneas de negocio o servicios y por lo tanto, incluso, en un mismo banco podemos tener más de un sufijo con lo que tendríamos que tener un mandato por cada sufijo aunque sean del mismo banco.Cada mandato hace referencia a un único identificador de acreedor y por lo tanto a un único sufijo. Por lo tanto tenemos que tener un mandato por cada sufijo diferente se tenga.Por ejemplo, podemos tener cinco bancos con un mismo sufijo y por lo tanto con un solo mandato valdría. Pero podemos tener cinco bancos con un sufijo diferente cada uno y por lo tanto necesitamos cinco mandatos

Which translates to:

The suffix is the comercial code of the company and it’s used to identify different business lines or services. In the same bank we can have more than one suffix which requires having a mandate for each suffix despite being of same bank. Each mandate references one unique identifier and therefore one unique suffix. For example we may have 5 bank accounts with the same suffix which require only a single mandate. On the other hand we may have 5 banks accounts with a different suffix which will require 5 mandates.

In review, a point was raised that some banks may request a different initiator identifier depending on the type of document generated. For me, it is an unnecessary complexity imposed by a poor implementation on the bank side (most of the example on the net show the no identifier are used, just the name). So I think for user in this case the simplest would be to use two journal with different configuration.

I’ve checked with 4 different banks (Sabadell, Caixabank, Santander and Ibercaja) and all use the same identifier:

  • ESDDXXXZZZZZZZZ is used for receivable formats
  • ZZZZZZZZXXX is used for payable formats

See previous post for the explanation about the encoding used

Although the proposed solution works i do not think it provides the best User Experience as it’s strange to have to use two different journal to specify the identifier on each journal when it’s possible to define two (receivable and payable) formats on the same journal. I think it’s better (and not so complex) to allow to define for each format the identifier used by using two different fields on the same journal.

Maybe but it makes no sense to use for exactly the same tag different values (and header which by the way is absolutely not required and only there for authentication) as the goal it to identify the party so the same identity should work for all cases.
It seems that only Spanish banks are requesting that.

Could you provide the explanation of each bank about this specific InitgPty tag for both cases?

Finally, you are right that we should have a better UX for those cases. So I decided in the last patch to put two identifier fields, one for receivable and one for payable. This will not complicate too much the UI for other users.