Data carrier exchange procedure
The data carrier exchange procedure ( DTA or DTAUS ) is a procedure in cashless payment transactions .
In 1976, the Central Credit Committee (ZKA; today Die Deutsche Kreditwirtschaft ) agreed on the data carrier exchange format (DTAUS format) for domestic payments . This uniform standard enables the electronic processing of payment orders ( transfers and direct debits ) in German domestic payment transactions . For merchants (non-consumers), the DTAUS procedure will be discontinued by August 1, 2014 (execution date) and replaced by the SEPA procedure. Private individuals (consumers) were able to submit their payments in the usual form until February 1, 2016.
The format is also used to transmit account statement information from the bank to the customer, although MT940 is actually intended for this .
As a counterpart to the DTAUS format, the DTAZV format (data carrier exchange for foreign payment transactions) was adopted in the ZKA in 1986 for the paperless processing of foreign payment transactions.
application
In the data carrier exchange process, so-called DTA files are passed on in DTA format . These can be stored on magnetic tapes , tape cassettes, floppy disks , memory cards or a similar medium, or they can be transferred electronically via remote data transmission (even if the name is no longer entirely correct because the physical data carrier is missing). Modern online banking portals already enable the upload of DTA data via web interface solutions. In Germany, the BCS -FTAM procedure for business customers to exchange data is (still) very widespread. A well-known (client) software product for BCS is “Multicash”, which is sometimes also used to describe the process. In the private customer area, in addition to the online banking portals, the FinTS interface (formerly HBCI ) is mainly used for software access. FinTS also uses (partially) the DTA and DTAZV format to transmit user data.
The legitimation and authorization of the orders on the original transmission path is carried out by a so-called "data carrier accompanying note" with the signature of an authorized representative. When transmitting electronically, the legitimation and authorization can be carried out, for example, using the PIN / TAN procedure, the electronic signature (EU) from BCS-FTAM or the various HBCI security procedures (chip card / RSA file). Data carrier accompanying notes can still be used in isolated cases for electronic transmission.
The files are used for exchange between credit institutions (banks) and between customer and credit institution. The exchange of physical data carriers between the credit institutions was also known as garage clearing . This name comes from the fact that the magnetic tapes used to be often exchanged in the underground car parks of the central banks. This method became obsolete with the introduction of electronic exchange procedures and the subsequent elimination of magnetic tapes.
Disk
Originally mostly 9-track magnetic tapes were used as data carriers , later floppy disks were also used. Some of the larger banks were also connected with leased lines. With the advent of Datex-P , this service was also used. Some banks offer the option of uploading data using online banking . The physical exchange of data carriers has hardly been used since around 2000.
Structure of DTAUS files
The format is described in the data transmission agreement in Appendix 3 "Specification of the data formats".
A physical DTA file can consist of several logical DTA files. These in turn consist of an A record (data carrier prefix), one or more C records (exchange of payments) and an E record (data carrier suffix). The physical record length is 128 bytes, A record and E record each consist of a record of 128 bytes, C record of a minimum of 2 record sections (physical records) of 128 bytes. The following description refers to the so-called diskette format (with DE-ASCII fields - German variant of ASCII limited to capital letters and ß). The magnetic tape format with EBCDIC and packed fields is used between the banks (the technical content is largely identical).
A sentence
It mainly describes the (next) destination and the type of file (bank → bank or customer → bank and credit or direct debit transactions). The record length is exactly 128 characters.
Meaning of the columns in the following sentence description:
- Field no.
- Number of the field within the record
- position
- Offset from the beginning of the record
- length
- Field length
- Type
- Field type
- alpha : alphanumeric, left-justified unused positions 0x20 (space, ASCII 32)
- numeric : numeric data, unpacked, right justified with leading zeros
| Field no. | position | Length (characters) | Type (characters) | Explanation | content |
|---|---|---|---|---|---|
| 1 | 0 | 4th | numerically | Record length | 0128 |
| 2 | 4th | 1 | alpha | Record type | A. |
| 3 | 5 | 2 | alpha | Mark | "GK" or "LK" "GB" or "LB" reference to credits (G) or direct debits (L), customer disk (K), bank disk (B) |
| 4th | 7th | 8th | numerically | BLZ file recipient (i.e. ordering bank) | |
| 5 | 15th | 8th | numerically | Sort code from sender bank | Only used if the file sender is a credit institution, otherwise 00000000 |
| 6th | 23 | 27 | alpha | Name of sender (client) | |
| 7th | 50 | 6th | numerically | File creation date | DDMMYY |
| 8th | 56 | 4th | alpha | Spaces | |
| 9 | 60 | 10 | numerically | Sender's account number (client): The equivalent value is charged to this account | In the case of customer files (code "GK" or "LK") this is usually the account number that is also in the C record in field C11. In the case of bank files, interbank clearing accounts are entered here instead. |
| 10 | 70 | 10 | numerically | if applicable, collective reference number of the submitter, otherwise zeros | 0000000000 |
| 11 | 80 | 47 | alpha | Spaces | optionally after 15 spaces (= A11a) the execution date (DDMMYYYY) (8 characters, = A11b), followed by 24 spaces (= A11c) |
| 12 | 127 | 1 | alpha | currency | 1 = euro |
C phrase
The actual posting is defined in the C record (accounts involved, amount and type of transaction as well as information on the intended use). The minimum scope is shown below. The record length of the main record is exactly 256 characters. The main set can be supplemented by up to 15 extension parts, which can lead to extension blocks.
| Field no. | position | Length (characters) | Explanation | content | |
|---|---|---|---|---|---|
| 1 | 0 | 4th | Record length | Length of the data record according to the formula 187 + x * 29 (x = number of extension parts = "lines"; example: 2 lines = 187 + 2 * 29 = 245) with a leading 0, i.e. 0245 in the example.
With 0 extension parts, 0187 is here and field 22 is padded with blanks - the data record does not end until the 256th character. |
|
| 2 | 4th | 1 | Record type | C. | |
| 3 | 5 | 8th | Bank code first participating bank (optional) | if bank code is not specified: 00000000 | |
| 4th | 13 | 8th | Bank code beneficiary (for transfers) or paying agent (for direct debits) | ||
| 5 | 21st | 10 | Account number of beneficiary or debtor | ||
| 6th | 31 | 13 | internal customer number | 0000000000000 | |
| 7a | 44 | 2 | Text key | 04 = Direct debit 05 = Collection 51 = Transfer 53 = Salary 54 = Asset-forming services 56 = Public coffers 67 = Transfer credit with check-digit-secured allocation data 68 = Credit from neutral transfer / payment slip 69 = Credit from a donation transfer | |
| 7b | 46 | 3 | Text key completion | in accordance with Appendix 1 of the EDI Agreement | |
| 8th | 49 | 1 | Spaces | ||
| 9 | 50 | 11 | Zeros | Previously: Amount in DM with 9 places in front of the decimal point and 2 places after the decimal point without separators | |
| 10 | 61 | 8th | BLZ client | ||
| 11 | 69 | 10 | Customer account number | This account number is communicated to the beneficiary / payer and z. B. used for returns. | |
| 12 | 79 | 11 | amount | 9 places in front of the decimal point and 2 places after the decimal point without separators | |
| 13 | 90 | 3 | Spaces | ||
| 14th | 93 | 27 | Name of beneficiary (or debtor in the case of direct debits) | ||
| 15th | 120 | 8th | Spaces | ||
| 16 | 128 | 27 | Name of client | ||
| 17th | 155 | 27 | Usage | ||
| 18th | 182 | 1 | currency | 1 (= EUR) | |
| 19th | 183 | 2 | Spaces | ||
| 20th | 185 | 2 | two-digit number | Number of extension data records, "00" to "15" | |
| 21st | 187 | 58 | Space for up to two extension parts | Up to two extension parts of 29 bytes each, padded with spaces | |
| 22nd | 245 | 11 | Spaces |
This is followed by space for the up to 4 × 128 bytes of expansion blocks. In the first 3 blocks, up to 4 extension parts with 2 byte prefix + 27 byte data = 29 bytes can follow one another. Unused bytes of such a 128-byte block are padded with 0x20 (space). The 4th expansion block is structured like the first 3, but contains only one expansion part if it is required. The rest of the 128 bytes are also filled with 0x20.
Extension parts
A C record can contain up to 15 extension parts of 29 bytes each. B. allow a longer use. An extension part consists of a 2 byte prefix and 27 bytes of content.
There are the following types of extension parts:
| prefix | Maximum amount | Explanation |
|---|---|---|
| 01 | 1 | Extension for "beneficiary" (field 14 in the C sentence) |
| 02 | 13 | Extension for "intended use" (field 17 in the C sentence) |
| 03 | 1 | Extension for "transferring party" (field 16 in the C sentence) |
As described in the C sentence, there is room in the C sentence for up to two extension parts, followed by 11 spaces. The remaining extension parts are appended in blocks (4 extension sets of 29 bytes each + 12 byte spaces) at the end of the C record. Each extension record increases the record length (field 0) of the C record by 29 and the number of extension parts (field 20) by 1.
Version 1.8
Version 1.8 of the specifications for electronic payment transactions of the Deutsche Bundesbank came into force on December 6, 2010 . Excerpt for changes to the C record, taken from the specification, field positions and lengths unchanged as described above:
| No. | field | meaning |
|---|---|---|
| 1 | C2 | Record type, constant "C" |
| 2 | C3 | Bank code of the first payment service provider involved (optional, provided that it is identical to the payer's payment service provider) |
| 3 | C4 | Bank code of the payee's payment service provider |
| 4th | C5 | Payee account number |
| 5 | C6 | Zero or EZÜ marking and ref. Allocation by payment service provider with bank code :
Occupancy by account holder without bank code :
|
| 6th | C7a | Text key, identification of the payment type according to Appendix 3 to the agreement on paperless data exchange ... |
| 7th | C7b | Text key extension according to Appendix 3 to the agreement on paperless data exchange ... |
| 8th | C8 | Bank-internal field, if not used Space |
| 9 | C9 | Reserve field = 0 |
| 10 | C10 | Bank code of the payer's payment service provider |
| 11 | C11 | Account number payer (In the case of payments for which the Deutsche Bundesbank is the payer's payment service provider, an account number belonging to the Deutsche Bundesbank account group must be entered.) |
| 12 | C12 | Euro amount, right-aligned (Fields for amounts in euros always contain two digits for cents.) |
| 13 | C13 | Reserve, space |
| 14th | C14a | Name of payee, left-aligned |
| 15th | C14b | Reserve, space |
| 16 | C15 | Name payer, left-justified |
| 17th | C16 | Usage (The information should be as brief as possible. At the beginning of this field, such information must be left-aligned that the payee may intend to access automatically when making transfers - e.g. building society account number, insurance number, invoice number). |
| 18, 19 | C17 | Reserve, space |
| 20th | C18 | Extension indicator
|
E-phrase
The E-record consists of a counter of the C-records and checksums (amounts, bank codes and account numbers ) to protect the file from transmission errors. The record length is exactly 128 characters.
| Field no. | position | Length (characters) | Explanation | content |
|---|---|---|---|---|
| 1 | 0 | 4th | Record length | 0128 |
| 2 | 4th | 1 | Record type | E. |
| 3 | 5 | 5 | Spaces | |
| 4th | 10 | 7th | Number of data records C | |
| 5 | 17th | 13 | formerly: total DM amounts | 0000000000000 |
| 6th | 30th | 17th | Sum of account numbers | |
| 7th | 47 | 17th | Total bank code | |
| 8th | 64 | 13 | Sum of euro amounts | 11 places before the decimal point and 2 places after the decimal point without separator |
| 9 | 77 | 51 | Spaces | "" |
Allowed characters
The following symbols are permitted at DTA:
| Approved character code | character | DIN-66003 hex code | would correspond in ANSI / Unicode |
|---|---|---|---|
| Numeric characters | 0 to 9 | 0x30 - 0x39 | "0" - "9" |
| Capital letter | A to Z | 0x41 - 0x5A | "A" - "Z" |
| Spaces | "" | 0x20 | "" |
| Point | "." | 0x2E | "." |
| comma | "," | 0x2C | "," |
| Commercial "and" | "&" | 0x26 | "&" |
| Hyphen | "-" | 0x2D | "-" |
| slash | "/" | 0x2F | "/" |
| Plus sign | "+" | 0x2B | "+" |
| star | "*" | 0x2A | "*" |
| dollar | "$" | 0x24 | "$" |
| Percent sign | "%" | 0x25 | "%" |
| Umlauts and ß | "Ä", "Ö", "Ü", "ß" | 0x5B, 0x5C, 0x5D, 0x7E | "[", "\", "]", "~" |
When encoding the characters, the data transmission agreement in Appendix 3 prescribes the DIN 66003 coding, in which the German umlauts and the ß are defined in the ASCII coding area. DIN 66003 is the German name for the German part of the international standard ISO 646 . In its specification, the Bundesbank mentions an encoding of the characters using the MS-DOS code page 437 . Both codings do not correspond to the widely used ISO-8859 coding, which is not specified in either of the two specifications as a valid coding of a DTAUS file. Code page 20106 corresponds to DIN 66003.
The banks assume no liability for the correct expression of characters that differ from the specification. The financial institution can convert lower case letters in data records into upper case letters or return or reject these data records to the submitter; It can convert impermissible special characters into blanks.
Requirement for use as a customer
In order to be able to take part in the data carrier exchange process as a customer (e.g. as an association), you need a program that can create a DTA file and a credit institution that accepts it. Many banks and savings banks offer this service for clubs or companies. In order to collect receivables by direct debit that are to be transferred via DTA, the account holder must join the direct debit agreement of the banks.
Further information is available from the Bundesbank, the central banks of the federal states or the local banks and savings banks.
Data carrier format in Austria
From January 1, 1999 (as part of the introduction of the euro as book money ), the V2 data carrier, which had been similar to the DTAUS format, was replaced by EDIFACT . The data records are sent between the banks in FINPAY format, between customer and bank as PAYMUL (transfer) and DIRDEB (direct debit) as well as CREMUL and DEBMUL (credit or debit note).
Data carrier format in Switzerland
The format for DTA files in Switzerland is determined by Swiss Interbank Clearing . The definition can be found under the web links.
Future development
As part of the standardization of the European payment transaction systems within the European Payments Area (SEPA), the data carrier exchange process has undergone fundamental changes since February 2008. The previous DTA format is to be replaced by messages based on the ISO20022 standard ( XML format) that are valid throughout Europe , and the FTAM process by the so-called EBICS process. The full replacement is currently planned for the period 201x. As of August 1, 2014, banks may no longer accept DTAUS files from the customer for posting; from February 1, 2016, DTAUS files may no longer be used within the banks for debit card and EC card payments.
Web links
- Annex 3 of the interface specification for remote data transmission between customers and credit institutions in accordance with the agreement on remote data transmission between customers and credit institutions , page 4 ff
- Formats in payment transactions
- Swiss format for DTA files (PDF; 1,295 kB)
Individual evidence
- ↑ a b Die Deutsche Kreditwirtschaft: Appendix 3 of the interface specification for remote data transmission between customer and credit institution in accordance with the data transmission agreement. ( Page no longer available , search in web archives ) Info: The link was automatically marked as defective. Please check the link according to the instructions and then remove this notice. (PDF; 7.6 MB) Version 2.7 from March 25, 2013. Accessed June 8, 2013.
- ↑ Monitoring of payment transactions and securities processing. Retail payment systems. Deutsche Bundesbank , accessed on February 12, 2015 .
- ^ Katja Heyder, Hermann Fürstenau: Garagenclearing goes Sepa. (PDF; 262 KB) (No longer available online.) Journal for the entire credit system, archived from the original on February 12, 2015 ; accessed on February 12, 2015 (edition 2/2013, p. 26). Info: The archive link was inserted automatically and has not yet been checked. Please check the original and archive link according to the instructions and then remove this notice.
- ↑ Specifications for the electronic payment transactions of the Deutsche Bundesbank ( Memento of the original of April 10, 2006 in the Internet Archive ) Info: The archive link has been inserted automatically and has not yet been checked. Please check the original and archive link according to the instructions and then remove this notice.
- ↑ Specifications for the electronic payment transactions of the Deutsche Bundesbank ( page no longer available , search in web archives ) Info: The link was automatically marked as defective. Please check the link according to the instructions and then remove this notice. (PDF)
- ↑ German Bundesbank: Cashless payments. ( Memento of the original from June 7, 2013 in the Internet Archive ) Info: The archive link was inserted automatically and has not yet been checked. Please check the original and archive link according to the instructions and then remove this notice. Retrieved June 9, 2013.
- ↑ European Parliament and European Council: Regulation (EU) No. 260/2012 of the European Parliament and of the Council of March 14, 2012 laying down the technical regulations and business requirements for credit transfers and direct debits in euros and amending Regulation (EC) No. 924/2009 , accessed May 25, 2014
