SEPA remittance information and the EPC QR code: what actually survives

lmaa.space
23 August 2026
PAP-009

A payer who scans an EPC QR code can carry a single free-text field of 140 characters through to the payee's bank statement. That field is the only one in the code that both travels with the money and is free for the payee to shape. Structuring it with a delimiter is not a workaround, because the European Payments Council recommends exactly that and names the slash and the plus sign as the delimiters. Two things break the plan as posed. A vertical bar is outside the permitted character set, so a bank may replace it or reject the whole submission, and the field that looks made for a consent flag never reaches the payee at all. The real ceiling is 140 characters of a 73-character alphabet, in one field, delimited by / or +, and it is a ceiling the payer may edit before confirming.

1. EPC069-12: the code itself

Version and status

The current document is EPC069-12 version 3.1, "Quick Response Code: Guidelines to Enable the Data Capture for the Initiation of a SEPA Credit Transfer", issued 19 March 2024 and effective the same day. Its version history runs v1.0 in 2012, v2.0 on 2 July 2015, v2.1 on 9 February 2016, v3.0 on 13 September 2022, and v3.1 on 19 March 2024. The document is five pages long and the whole normative content sits in section 2.

The document is not binding on anybody. Section 1 states: "This document is of an informative nature only ... Therefore, it is optional for PSPs adhering to the SCT scheme to implement this feature and offer it to their customers." A bank that ignores the code is compliant, and nothing in the scheme obliges any bank to read it.

Section 1 also scopes the guidelines. They suit cases where the transaction data in the code "is also shown at the same time in plain text to the Originator (e.g., on an invoice presented/sent to the Originator)", which lets the payer check the code against the printed figures. For a code presented at a point of interaction, such as a terminal or a shopping cart, the EPC points instead to EPC024-22 "Standardisation of QR-codes for Mobile Initiated SEPA (Instant) Credit Transfers".

The fields, in order

The payload is a line-based text format. Elements are separated by a line feed or a carriage return plus line feed, one or the other consistently, and the last populated element carries no trailing separator. Trailing empty elements are dropped. The table below is section 2.2 of EPC069-12 v3.1 in full.

The amount must be at least 0.01 and at most 999999999.99. Only one of elements 10 and 11 may be populated. The "Fixed" column reproduces the document's own marker, whose legend reads: "X: fixed value i.e. the originator should not change the elements content when initiating the payment."

The payload limit and where it really bites

EPC069-12 section 2.1 sets three constraints together: error correction level M, meaning 15 per cent of code words can be restored; a maximum QR code version of 13, which is 69 modules square; and a total payload of 331 bytes. Section 2.2 repeats the byte limit and warns that "the number of characters may be less than the numbers of bytes with UTF-8."

Those three numbers are one number. QR version 13 at error correction level M holds exactly 331 bytes in byte mode under ISO/IEC 18004. Encoding 331 bytes produces a version 13 symbol of 69 modules, and 332 bytes forces version 14, which the guideline forbids. So the byte limit is not an EPC policy choice sitting on top of the QR version. It is the QR version restated.

For a payee with a short name and an Austrian IBAN the limit is not the constraint. A payload of BCD, 002, charset 1, SCT, empty BIC, a ten-character name, a twenty-character IBAN, EUR25, empty purpose, empty structured reference, and 140 ASCII characters of free text comes to 195 bytes, leaving 136 bytes spare. Every character of the free text costs one byte whilst it stays in ASCII. Every umlaut costs two under UTF-8, and 140 umlauts in that same payload would come to 335 bytes and fail. In that layout the free text can hold 278 single-byte characters before the payload limit is reached, so the 140-character field limit binds long before the byte limit does.

The character set field, and what it does not mean

Element 3 selects how the bytes of the payload are to be read: 1 for UTF-8, 2 for ISO 8859-1, 3 for ISO 8859-2, 4 for ISO 8859-4, 5 for ISO 8859-5, 6 for ISO 8859-7, 7 for ISO 8859-10, and 8 for ISO 8859-15.

This is a statement about the code, not about the payment. It tells the scanning app how to turn the QR code's bytes back into text. It says nothing about which of those characters the payment rails will carry, and the two answers are different. Section 2 covers the second question.

Which fields travel with the payment, and which do not

The distinction is visible in the table above and is not spelled out in prose anywhere in EPC069-12. Elements 5 to 11 each carry an AT- code, which is the identifier of an attribute in the SEPA Credit Transfer scheme dataset. Element 12, "Beneficiary to Originator information", carries none.

That absence is real rather than an editorial oversight. The string "Beneficiary to Originator" does not appear anywhere in the 2025 SCT Rulebook version 1.1, in the Customer-to-PSP Implementation Guidelines 2025 version 1.0, or in the Inter-PSP Implementation Guidelines 2025 version 1.0. There is no message element to put it in.

The Austrian specification that originated the format says so outright. STUZZA and the Austrian Payments Council, "Application of QR-Code for Initiating of Credit Transfers", version 3.0 of 1 May 2021, published through PSA Payment Services Austria, calls element 12 "Display" and gives it note 8: "The text contained in Display must be shown to the user after decoding and serves a short textual description of what the user is going to initiate. This text must not be forwarded with the data handed over to the payment system." Section 7 of the same document repeats it: "This text is to be displayed but not to be transmitted into the payment system."

So element 12 is a message from the payee to the payer, rendered in the banking app at the moment of confirmation and then discarded. A consent flag placed there would be seen by the person giving consent and by nobody else. That rules it out for the purpose at hand.

The only field that both travels and is free-form is element 11, the unstructured remittance information.

2. The character set of the unstructured remittance

The permitted set

Section 1.4 of the SCT Customer-to-PSP Implementation Guidelines 2025 version 1.0 states that "PSPs and their customers must be able to support the Latin character set commonly used in international communication" and then lists it exactly:

That is 26 lower case letters, 26 upper case letters, 10 digits, the space, and ten punctuation marks: slash, hyphen, question mark, colon, left parenthesis, right parenthesis, full stop, comma, apostrophe, and plus sign. Section 2.1 of the Clarification Paper on the SCT and SCT Inst Scheme Rulebooks, EPC131-17 version 3.1 of April 2025 repeats the same list word for word.

Two further rules appear in section 1.4, and both are narrower than they look. Content must not start or end with a slash and must not contain a double slash. Both apply only to "references, identifications and identifiers", not to free text. Section 3 of EPC217-08 "SEPA Requirements for an Extended Character Set (UNICODE Subset) Best Practices", version 1.1 of 18 December 2012 explains why the set is this short: "The limited character set reflects the need to ensure information can be, for example, printed on statements."

Not a ceiling in the XML, but a floor of support

The wording is a support obligation rather than a prohibition. Section 1.4 of the Implementation Guidelines opens with the constraint it is balancing: PSPs must be allowed to use the character set in use nationally, but PSPs across SEPA cannot be required to support every character set in SEPA. The same section notes that "The ISO 20022 XML messages allow for the full range of global language requirements (UTF-8)" and closes with "However, there may be bilateral or multilateral agreements to support one or more sets of characters beyond the Latin character set referred to above."

The Implementation Guidelines give the unstructured remittance element the type Max140Text, ISO length 1 to 140, and SEPA length 1 to 140, at index 2.165. They attach no Pattern to it, unlike the country code, IBAN, currency, and BIC elements, which all carry an explicit regular expression. Schema validation therefore does not reject a vertical bar or an umlaut. Whatever rejects it is a bank, not a parser.

What happens to a character outside the set

EPC217-08 section 3 describes the state of play plainly: "The current practice is that in lieu of rejecting a payment, some receiving banks replace unrecognised characters with blanks or other characters or simply delete them. This indicates that there is no common practice in place and introduces inefficiencies and uncertainty in processing."

The document's remedy is a conversion table with three tiers. Yellow entries are the basic Latin set above. Green entries are additions accepted for European languages and financial text, including Greek and Cyrillic letters, the cent, pound, plus-minus and euro signs, the inverted exclamation and question marks, and the tilde, which was accepted because it appears in URLs. Red entries sit outside the extended set, and section 6.1 says of them: "The presence of these characters can be the basis for a reject or be replaced by a full stop (U+002E)."

Section 6.2 gives senders substitutions for characters they need and cannot send: € becomes E, @ becomes (at), & becomes +, and _ becomes -. The same section requires the five XML special characters &, <, >, " and ' to be escaped.

None of this is binding. EPC217-08 is a best-practices paper from 2009, revised in 2012, and section 3 states that the solution "does not however mandate this solution upon the entire community as the impact and cost of doing so would be very significant." EPC131-17 v3.1 restates the character set but does not say what a receiving bank must do when a non-conforming character arrives.

Umlauts

For a German bank the answer is specific and better than the folklore. Die Deutsche Kreditwirtschaft, "DFÜ Agreement, Appendix 3: Specification of Data Formats", version 26.11 of 9 April 2026 lists the EPC Latin set as the permitted set for SEPA messages, and then adds a second table headed "For further characters which have been additionally permitted, the following regulation applies: 1. The financial institutions commit themselves to their adoption." That table contains Ä Ö Ü ä ö ü, ß, &, *, $, and %. The umlauts convert to A O U a o u if not displayable, with AE OE UE ae oe ue permitted as an alternative, and ß converts to s with ss permitted.

So a German bank commits to accepting umlauts and may still fold them. The text arrives, possibly spelled differently. For a value a human reads that is fine. For anything compared byte for byte it is not.

The Appendix goes on: "If characters are used which are not contained in this character set, the financial institution is entitled either to replace the non-admissible characters or to reject the complete file", with the footnote "Characters outside the above-mentioned character set prevent processing in the banks and the checks there."

Two smaller notes on the same document. Its table gives the dollar sign the hex code X'24' but the UTF coding U+0025, which is the code point of the percent sign; U+0024 is correct and the entry is a typographical error. And the document nowhere mentions QR codes or the GiroCode. Die Deutsche Kreditwirtschaft publishes no field specification of its own for the code, so EPC069-12 is the only specification of the payload in the German market as well.

The vertical bar

The vertical bar, U+007C, is not in the EPC basic Latin set, is not in the additional list Die Deutsche Kreditwirtschaft commits to, and is not among the characters EPC217-08 section 6.2 gives a substitution for. It is therefore a character a bank may silently replace or use as grounds to reject the submission. Using it as a field delimiter puts the entire structure of the message at the discretion of whichever institution first dislikes it, and the failure is silent: the payment still arrives, with the delimiters gone or turned into full stops.

The delimiter the EPC actually recommends

There is no need to invent one. Index 2.165 of the Customer-to-PSP Implementation Guidelines and index 2.138 of the Inter-PSP Implementation Guidelines both carry the same usage rule for the unstructured remittance:

The same guidelines state that "'Unstructured' may carry structured remittance information, as agreed between the Originator and the Beneficiary." So a delimited payload in the free-text field is the intended use, not a misuse.

Section 6 of EPC088-22 "EPC Guidance Document, Improve Transparency for Retail Payment End-Users", version 1.0 of 25 May 2022 is where that rule comes from, and its second illustration is directly relevant to carrying a link:

A bare host name passes. A full URL with a scheme does not, because https:// contains a double slash. That prohibition is written for references and identifiers rather than for free text, and EPC230-15 "Clarification Paper on the Use of Slashes in References, Identifications and Identifiers", version 2.0 of 16 February 2023 confirms it: its table marks even the structured creditor reference at index 2.175 as "NO, because it is part of the remittance information" under the heading "Impacted by the 'slash' rule?". Nothing in the remittance information is caught by the slash rule.

That same paper carries the counterweight, and it is the reason to prefer the plus sign: "A recipient (of a payment message) who does not receive ISO 20022 messages might experience issues when information contains slashes. It is therefore advisable to avoid the use of slashes as much as possible." The EPC recommends the slash as a delimiter in one document and advises avoiding slashes in another. The plus sign is named as the sanctioned alternative in the first, is in the basic Latin set, and is subject to neither caution.

Is the character set being extended?

No, not in the current cycle. The SCT Scheme Rulebook Public Consultation Document on 2026 Change Requests, EPC008-26, published 13 March 2026 contains no change request on the character repertoire. Three requests touch remittance information and all three concern the structured form.

Change request 18, from the EPC's own Scheme Evolution and Maintenance Standards Task Force, would remove the 140-character cap on the structured element, on the grounds that the ISO 20022 sub-elements available to SEPA amount to 164 characters. The working group recommends incorporating it with effect from November 2027. Change request 20, from the Swiss and Liechtenstein PSP community, would allow 140 characters of unstructured data to be carried inside the structured element as an additional element. The working group recommends not taking it forward, citing "a lack of a clear market need in combination with the investments to be made". Change request 21 would oblige the originator's PSP to validate a structured reference only when it is an ISO 11649 reference, and is recommended for incorporation.

The consultation closed on 11 June 2026, decisions are expected towards the end of summer 2026, and anything adopted lands in the 2027 rulebook published in November 2026 and effective November 2027. None of it changes the 140 characters of the unstructured field, and none of it changes which characters are permitted.

3. The 140 characters end to end

The forwarding obligation

Section 2.7 of the 2025 SCT Rulebook version 1.1, issued and effective 5 October 2025 and in force until 21 November 2027, is unambiguous about the middle of the chain: "The remittance data supplied by the Originator in the Credit Transfer Instruction must be forwarded in full and without alteration by the Originator PSP and any intermediary institution and CSM to the Beneficiary PSP." Section 3.3 places the same duty on clearing and settlement mechanisms, which must ensure "that all data intended by the Originator and the Originator PSP to reach the Beneficiary PSP and the Beneficiary is forwarded in full and without alteration".

The delivery obligation, and its escape hatch

Section 2.7 continues: "The Beneficiary PSP must also deliver received remittance data in full and without alteration to the Beneficiary."

Dataset DS-04, "The PSP-to-Customer SEPA Credit Transfer Information" in section 4.5.4, is the one that governs what the payee's bank owes the payee. It lists AT-T009 among its attributes and then qualifies the duty: "Where any of the above attributes, optional or not, are present in an Inter-PSP Payment message (DS-02) the contents must be made available in full by the Beneficiary PSP to the Beneficiary, subject to any prior agreement to the contrary."

Three things follow. The obligation is to make the content available, not to print it on any particular statement or screen. It can be contracted away by prior agreement. And DS-04 describes "the minimum information that a Beneficiary PSP needs to make available", so a bank that shows the full 140 characters in its online banking whilst truncating a monthly PDF is within the rules. The same section permits a beneficiary PSP to drop extended reference party information for a beneficiary "who uses an interface which does not comply with the ISO 20022 XML standard". That exemption is written for reference party data rather than for the remittance field, but it shows where the rulebook expects data to be lost, which is wherever a modern message meets an older reporting interface.

The rulebook documents no truncation of the unstructured remittance itself. The one length reduction it records is the opposite direction, and it is at the sending end: Die Deutsche Kreditwirtschaft's Appendix 3 notes that the SEPA guidelines cut the ISO 2019 allowance of 140 characters for party names down to 70.

Extended remittance information is not an option here

Annex V of the rulebook offers an Extended Remittance Information option, specified in EPC152-18 and described at section 2.21 of the Inter-PSP Implementation Guidelines. It carries one occurrence of 140 unstructured characters plus up to 999 structured occurrences of 280 characters each. It is unusable for a public donation code for one reason, stated in rulebook section 2.7: "A Participant that receives ERI as defined by this Rulebook option but is not an ERI Option Participant, shall transfer back the SEPA Credit Transfer Instruction or Transaction containing such ERI to the Originator or the Originator PSP as a Reject or as a Return". A payer whose bank has not adhered to the option would have the payment bounced. EPC069-12 has no field for it in any case.

4. Editability

EPC069-12 answers this directly, through the "Fixed" column of its data element table and the legend beneath it: "X: fixed value i.e. the originator should not change the elements content when initiating the payment."

Four elements carry that marker: the BIC, the beneficiary name, the IBAN, and the structured creditor reference. Four do not: the amount, the purpose code, the unstructured remittance information, and the "Beneficiary to Originator information". By the document's own logic the payer is free to change the free text before confirming. Even for the marked fields the wording is "should not", addressed to the originator rather than to the app, and the document is informative throughout.

The Austrian specification is stronger but still advisory. Section 7 of the STUZZA and Austrian Payments Council document version 3.0 reads: "It is strongly advised, especially for the receiver data and a possibly contained reference, to preserve the read data and not to allow alternation by the payer, as this will hinder the reconciliation and payee identification on receiving bank and beneficiary." The emphasis falls on the recipient data and the structured reference. It does not extend the advice to the free text.

The same section adds a second way for the payer's own words to enter the message: "It is permitted to offer the user the possibility to qualify an additional, 35 character long information before handing over the data to the payment system." That information is meant for the payer's own statement and may also be used as the originator's reference, which is set to NOTPROVIDED when the payer supplies nothing.

5. ISO 11649 as the structured alternative

ISO 11649:2009, "Financial services, Core banking, Structured creditor reference to remittance information" defines the RF Creditor Reference. Clause 5 gives the format as 2!a2!n21c, which is a total maximum of 25 characters: the two letters RF, two numeric check digits, and up to 21 further characters. The reference part "shall only contain upper and lower case letters (A to Z and a to z) and numeric characters (0 to 9), without special characters such as separators and punctuation".

Clause 6 specifies the check digits under ISO/IEC 7064 MOD 97-10, the same scheme the IBAN uses. To generate them, append RF00 to the reference, convert letters to digits with A as 10 through Z as 35, apply MOD 97-10, and take 98 minus the remainder. To validate, move the first four characters to the end, convert letters the same way, and confirm the remainder is 1. Annex A is normative and requires the printed form to keep the same structure but be set in groups of four characters separated by spaces, so RF68539007547034 becomes RF68 5390 0754 7034.

In the payment message the reference travels in RmtInf/Strd/CdtrRefInf/Ref. The Customer-to-PSP Implementation Guidelines set out the surrounding rules across indices 2.166 to 2.175. Structured may occur only once, and it may not be combined with Unstructured. The whole structured block, counting the sub-element tags but excluding <Strd> and </Strd>, may not exceed 140 characters. Type/CdOrPrtry/Cd accepts only the value SCOR. Issuer must be ISO when the reference is an ISO 11649 reference. The reference field itself is Max35Text, so SEPA allows 35 characters where ISO 11649 defines 25, and EPC069-12 likewise gives element 10 a 35-character maximum.

Two rules cut against treating the check digits as a guarantee. Index 2.169 says "the Debtor PSP is not obliged to validate the reference information". Index 2.175 says "If a Creditor Reference contains a check digit, the receiving PSP is not required to validate this. If the receiving PSP validates the check digit and if this validation fails, the PSP may continue its processing and send the transaction to the next party in the chain." Change request 21 in the 2026 consultation exists precisely to introduce a validation obligation for ISO 11649 references, which confirms that today there is none.

What ISO 11649 does buy is different, and it is worth having. The reference is marked fixed in EPC069-12, so the guidance is that the payer should not alter it. Its alphabet is a strict subset of the permitted Latin set, so no bank has a reason to fold or replace any character in it. It is a single opaque token, so nothing about it invites the payer to edit it the way a sentence does. And its check digits let the payee detect a mistyped or mangled reference on arrival rather than silently misattributing it. The rulebook recommends it: section 2.7 states that beneficiaries should adopt it "as the preferred remittance data convention for identifying payment referring to a single invoice", and AT-T009 repeats the recommendation.

Its cost is that it carries no content. 21 characters of [A-Za-z0-9] is roughly 125 bits of space, which is ample for an opaque identifier that a database resolves into a consent flag, a link, and a claim, and useless for carrying any of those three literally. It is also mutually exclusive with the free-text field, so a design cannot have both a reference and a sentence.

6. What this means for the plan as posed

The plan was a consent flag, a link, and a free-text claim, delimited, arriving on the bank statement. Set against the sources above it comes apart into three separate answers.

The consent flag and anything else that must be trustworthy cannot live in the free text, for two independent reasons. The payer may edit that field before confirming, and nothing obliges a banking app to prevent it. Characters outside the basic Latin set may be replaced or may cause a rejection, so even an untouched message can arrive altered. A flag that is sometimes absent because somebody deleted it, and sometimes malformed because a bank folded a character, is not a consent record.

The link and the claim can live in the free text, within the alphabet. A bare host name works, as the EPC's own illustration shows. A scheme prefix does not, because of the double slash, and an @ handle does not, because @ is outside the set and its sanctioned substitution is the four characters (at). Delimiting them is exactly what the guidelines recommend, and the delimiter should be + rather than |, and + rather than / because EPC230-15 advises against slashes for recipients on older reporting formats.

The reliable shape, if one is wanted, is an ISO 11649 reference in element 10 that identifies a record the sponsor filled in on the site beforehand, with the consent, the link, and the claim held there. That moves every one of them out of the payment message, where they are subject to the payer's editing and the banks' character handling, and leaves the payment carrying only a check-digited token whose alphabet no bank has cause to touch. It costs the free-text field, since the two are mutually exclusive.

A middle course is possible and should be understood as best-effort: put the reference in element 10, and put a human-readable greeting in element 12, which the payer sees at the moment of confirmation and which never reaches the statement. That uses element 12 for the one thing it is actually for.

Two figures to hold on to. 140 characters is the field limit and 331 bytes is the payload limit, and in a realistic layout the first binds long before the second, so the byte budget is not the thing to design around. And the permitted alphabet is 73 characters wide, which is the number that decides whether a given delimiter, handle, or URL survives.

7. Two follow-up questions on the structured block

7.1 Can the structured block carry free text alongside the creditor reference?

No, and it fails three times over. The element exists in the message but is not part of the SEPA core service, the arithmetic leaves no room for it even if it were, and the QR code has no way to ask for it.

The element is white, not yellow

AddtlRmtInf appears in the Customer-to-PSP Implementation Guidelines 2025 version 1.0 at index 2.180, with multiplicity 0..3, type Max140Text, ISO length 1 to 140, and SEPA length 1 to 140. It appears in the Inter-PSP Implementation Guidelines 2025 version 1.0 at index 2.153 with the same multiplicity and type. In both documents the row is shaded white rather than yellow. Rendering page 41 of each guideline at 150 dpi and sampling the table body returns no yellow pixels at all, against roughly 26.000 on the page carrying the unstructured and structured remittance rows, where the shading measures RGB 249, 253, 94. Neither entry carries a SEPA Rulebook attribute line or a SEPA Usage Rule, which the guidelines attach only to core elements.

Section 1.1 of the Customer-to-PSP guidelines gives the legend. Yellow elements "define the SEPA core service". White shading marks elements "that may be available for use in an AOS, subject to a governance framework to be defined by the EPC", where an AOS is an Additional Optional Service, and "The definition and documentation of these message elements are a matter for the AOS communities involved." Section 1.2 states the consequence: "The instructed PSP receiving a message containing AOS message elements, but which is not a member of this AOS community, may ignore the information, that is, not use it for processing, nor forward it to the next party in the chain. The instructed PSP, however, may reject the message for this reason."

The 2026 change request consultation, EPC008-26 says the same thing in words. Change request 20, which would have permitted 140 characters of unstructured data inside the structured element, notes at section 2.12.1: "The message element 'Additional Remittance Information' is currently a white message element and would then become a yellow (optional) message element." The working group recommends not taking it forward.

The 140-character cap leaves nothing

Index 2.166 of the Customer-to-PSP guidelines states the format rule: "'Structured' can be used, provided the tags and the data within the 'Structured' element (i.e. excluding <Strd> and </Strd>) do not exceed 140 characters in length." A minimal creditor reference block carrying a 16-character RF reference reads as follows.

That is 113 characters, so 27 of the 140 remain. The wrapper <AddtlRmtInf></AddtlRmtInf> is 27 characters by itself, which leaves exactly zero for content. Push the reference out to the 35 characters SEPA permits and the block reaches 132 characters, so the wrapper no longer fits at all. The two cannot coexist in a SEPA credit transfer whatever the colour of the element, and change request 18 in the same consultation exists to lift that cap precisely because the ISO 20022 sub-elements available to SEPA would otherwise total 164 characters.

A German bank forbids it outright

Die Deutsche Kreditwirtschaft, "DFÜ Agreement, Appendix 3: Specification of Data Formats", version 26.11 of 9 April 2026 sets out the remittance limits in a table and closes the row on structured remittance information with one sentence: "The only subtree permitted is 'Creditor Reference Information'."

And the QR code cannot ask for it in any case

This is the half that settles the matter regardless of the XML. Section 2.2 of EPC069-12 v3.1 defines exactly twelve elements, and the structured remittance is a single field of at most 35 characters holding a creditor reference. There is no thirteenth element, no repetition, and no sub-structure. A scanning app given an EPC QR code has nothing from which to populate AddtlRmtInf, so even a bank belonging to an AOS that supported the element would have no input to put in it. The question closes here.

7.2 The payer's own 35 characters

The field is the End To End Identification, it is mandatory, and it does reach the payee. It is also entirely the payer's, which is what limits its use.

Which element

Index 2.81 of the Customer-to-PSP Implementation Guidelines maps EndToEndId to "AT-T014 The Originator's Reference of the Credit Transfer Instruction", with multiplicity 1..1, type Max35Text, and SEPA length 1 to 35. It is not the payment information identification, which is a separate element. The ISO definition reads: "Unique identification assigned by the initiating party to unambiguously identify the transaction. This identification is passed on, unchanged, throughout the entire end-to-end chain."

Index 2.3 of the Inter-PSP Implementation Guidelines carries the same attribute for the interbank message and adds the usage rule that explains the STUZZA note: "A customer reference that must be passed on in the end-to-end chain. In the event that no reference was given, 'NOTPROVIDED' must be used." The 2025 SCT Rulebook version 1.1 states the same default in the value range of AT-T014, though it spells it "Not provided" in prose whilst the guidelines require the literal NOTPROVIDED.

Whether it reaches the beneficiary

It does, under the same rule as the remittance information. Dataset DS-04 in section 4.5.4 of the rulebook lists "T014 The Originator's reference of the Credit Transfer Transaction" among its attributes, alongside T009. The rule applied to the whole dataset covers both identically: "Where any of the above attributes, optional or not, are present in an Inter-PSP Payment message (DS-02) the contents must be made available in full by the Beneficiary PSP to the Beneficiary, subject to any prior agreement to the contrary." The exemption further down that dataset, which lets a beneficiary PSP drop data for a beneficiary on a non-ISO-20022 interface, names attributes P006, P007, E007, E010 and T007. T014 is not among them, and neither is T009.

What that makes it

A second channel of 35 characters that survives alongside a creditor reference, since the two live in different parts of the message and neither excludes the other. It is stronger than the remittance field in two respects. It is mandatory rather than optional, so it is always present even if only as NOTPROVIDED. And the rulebook says of it that the reference "must be returned in any exception handling process-step by any party involved", which the remittance field has no equivalent of.

Three things limit it, and together they mean it cannot be designed around. The payee cannot pre-fill it, because EPC069-12 has no element for the originator's reference and the STUZZA document is explicit that the payer supplies it after scanning. Section 7 of the STUZZA and Austrian Payments Council specification version 3.0 says an app is "permitted to offer the user the possibility to qualify an additional, 35 character long information", which makes both the field and its use optional at the app's discretion. Its content is restricted more tightly than the remittance text, because it is a reference: EPC230-15 version 2.0 marks index 2.81 as "YES" under "Impacted by the 'slash' rule?", so it must not start or end with a slash nor contain a double slash, and section 1.4 of the Implementation Guidelines restricts its content to the Latin character set with no room for the bilateral agreements that free text enjoys. And the rulebook's own description of AT-T014 warns against reading anything into it: "The Originator must define the internal structure of this reference; it can only be expected to be meaningful to the Originator."

So it is worth reading on arrival, because it costs nothing to read and it will sometimes carry a name or a note the payer typed. It is not somewhere the payee can put anything, and it cannot be relied upon to hold anything in particular.

8. What could not be verified against a primary source

The EPC conversion table spreadsheet referenced by EPC217-08 section 6.1, EPC217-08_SEPA_Conversion Table V_10.xls, could not be retrieved. Every direct URL tried returned a Cloudflare interstitial rather than the file. The statement that the vertical bar is outside the extended SEPA character set therefore rests on its absence from the basic Latin set in the Implementation Guidelines and from the additional list in Die Deutsche Kreditwirtschaft's Appendix 3, both of which were read in full, and not on the conversion table itself. Whether the table assigns the vertical bar a green entry, a red entry, or no entry at all is unconfirmed.

The XSD accompanying the Customer-to-PSP Implementation Guidelines, EPC132-08 SCT C2PSP IG 2025 V1.0 XSD.zip, could not be retrieved for the same reason. The claim that no pattern restricts the unstructured remittance element rests on the Implementation Guidelines themselves, where index 2.165 lists a type and two lengths and no Pattern row, whilst other elements in the same document do carry one. It has not been checked against the schema file.

The ISO 20022 definition of Max140Text was not read at source. Attempts to fetch a pain.001.001.09 schema from iso20022.org returned an interstitial page and then timed out. The statement that the ISO type imposes a length bound and no character restriction rests on the Implementation Guidelines, which give ISO length 1 to 140 and attach no pattern, and on EPC217-08 section 3, which states that the ISO 20022 XML message standards "support all UNICODE characters".

ISO 11649:2009 was read from the publicly published preview PDF hosted by iTeh Standards, which contains the front matter, clauses 1 to 6, and Annex A in full. The full standard behind the ISO catalogue entry is paywalled and was not purchased. Annex B, the informative worked example of the check digit calculation, is truncated in that preview. The check digit algorithm as described here comes from clause 6, which is complete, and was confirmed by computing it: the reference RF18539007547034 used in the EPC069-12 v3.1 example validates correctly under MOD 97-10. The reference RF68539007547034 printed in ISO 11649 Annex A does not validate. That is either a different base reference than it appears to be, or an error in the standard's own example. The preview does not contain enough of Annex B to tell which, so this is recorded rather than resolved.

Die Deutsche Kreditwirtschaft publishes no specification of the GiroCode payload. Searches of die-dk.de and die-deutsche-kreditwirtschaft.de produced only material on paper payment forms. Appendix 3 to the DFÜ Agreement, which was read in full for its character set chapter, does not mention QR codes anywhere. The conclusion that EPC069-12 is the only field specification of the code in the German market is drawn from that absence and could be overturned by a document not published on either domain.

The STUZZA and Austrian Payments Council document is version 3.0 of 1 May 2021. Whether a newer version exists behind the PSA download portal's archive section was not checked.

Whether any specific Austrian or German bank truncates the unstructured remittance in its own statements, exports, or camt reporting is not addressed by any of these documents and was not tested. The rulebook sets the floor. What an individual institution shows is a question for that institution, and the same holds for the End To End Identification discussed in section 7.2.

The shading of AddtlRmtInf was established by rendering pages 41 of both Implementation Guidelines at 150 dpi and counting pixels, and separately by the wording of change request 20 in EPC008-26. The Implementation Guidelines were not read in a viewer that reports fill colours from the PDF content stream, so the figures come from the rasterised page rather than from the document's own colour definitions. The two methods agree and the consultation document states the conclusion in words, so this is recorded for completeness rather than as a doubt.

Whether an AOS community exists anywhere in SEPA that has defined and documented AddtlRmtInf for use is not knowable from these documents. Section 1.1 of the Customer-to-PSP Implementation Guidelines leaves the definition of AOS elements to the communities involved and to a governance framework "to be defined by the EPC", and the EPC publishes no register of them that was found. The practical answer in section 7.1 does not depend on this, because the QR code cannot populate the element in any case.

Which message element a given banking app writes the payer's own 35 characters into is not specified anywhere. The STUZZA and Austrian Payments Council document permits the app to use that input for the originator's reference without requiring it, and no EPC document addresses the question. The mapping to EndToEndId in section 7.2 is the mapping of AT-T014, which is what the STUZZA text names, and not an observation of any app's behaviour.

Sources

Eleven documents, in the order in which they first carry weight. Every one is linked at the point in the text where it is used; this list gathers the versions and the access notes.