If the internal address-table is to be used, the following table structure will be used. The contact persons per address are stored in a separate table PTC - Contact Person per Party / Address. The link of addresses to parties which are stored in the Table PTY - Party are build via entries in the Table PTA - Party Address Association.

Unique internal ID of a record within the table. The INR is a text field, which is created by retrieving the next valid entry from the counter of this table. The field INR is used to enable links from other tables to this table.

For contractdata the INR also links the two tables xxD and xxT as associated entries hold the same INR.

The external key is used to uniquely identify an address. The key may consist of both letters and digits and is usually the unique ID under which a customer or correspondent bank is identified at a bank.

The external key can be used to search for an address that is already stored in the database.

This field contains a descriptive name (of up to 40 characters) used to identify an address. The name entered in this field is not used for correspondence, but is used to identify records with long names in a selection list or for other display and identification purposes.

Searching within a table is usually be done by entering parts of this field. All matching records are usually displayed to enable the selection of the desired address.

This field contains the optional ISO bank identifier code (BIC) of the address. Searching within a table is usually be done by entering parts of this field. All matching records are usually displayed to enable the selection of the desired address.

The BIC is used to uniquely identify the address in all S.W.I.F.T messages. The SWIFT BIC is made up of a maximum of 11 characters, and a minimum of 8 characters.

This field is used to define if SWIFT authenticator keys have been exchanged for this particular address.

This information is used to establish if all categories of SWIFT messages can be exchanged with the bank stored in this address. If this field is blank, then no SWIFT messages can be exchanged with this bank.

Permitted values: Not connected = no SWIFT connection Connected = no authenticator, only SWIFT message 999 can be exchanged with this address Authenticated = authenticator available to exchange all types of SWIFT messages

This field contains the location (town) used to identify the branch (not a SWIFT branch code). This field may be filled in only if a SWIFT BIC for this address is not available.

When the branch identification (BID) is specified, it is used to identify the address in a SWIFT message (option B of SWIFT field tags 52, 54 and 57 in certain message types).

It is not possible to send SWIFT messages directly to an address that is only identified by its BID.

This field contains the 8-digit German Bankleitzahl (BLZ) or the bank clearing code. Hence, this field can be filled in only for banks and financial institutions located in Germany and which have been assigned a BLZ.

This field is used to indicate the national clearing system code of the address. E.g.: CHIPS universal identifier (US) , or CHAPS branch sort code (UK), etc. German BLZs should not be entered here, but in the separate field defined for this purpose.

Identifies the department for communication and correspondence.

This field contains the Email address of the recipient.

This field contains a fax number for the recipient. Up to two fax numbers can be stored per address.

This field contains a fax number for the recipient. Up to two fax numbers can be stored per address.

This field contains the name of the institution or person, which/whose address is being set up here.

This field contains the second line in the name of the institution or person, which/whose address is being set up here.

This field contains the name of the institution or person, which/whose address is being set up here.

This field contains the house number and the name of the street of the addressee.

This field contains the optional second line of the street in the address.

This field contains the postal code of the location (town). (ZIP code in US, PLZ in Germany, etc.)

This field contains the name of the city.

This optional field contains the district of the city or additional information on the city.

This field contains the name of the country for the address.

This field is used for defaulting the preferred method of correspondence for this address.

This field is used to specify the post office box number of the addressee. If this field and the zip code of the P.O.Box address contain entries, then all surface mail is routed to the P.O.Box.

This field is used to specify the postal code of the post office box address. If this field and the P.O.Box number contain entries, then all surface mail is routed to the P.O. Box.

This field contains the name of the city.

This field is used to specify the telephone number. Up to two different telephone numbers may be specified.

This field is used to specify the telephone number. Up to two different telephone numbers may be specified.

This field is used to specify the unique ID of the addressee that is used for sending and receiving TradeConnect messages. The TID is 8 characters long.

This field contains the telex number for the recipient.

This field is specifies if a telex authenticator has been exchanged with this address.

The language code defines the language for corresponding with the address concerned. The system will default this language code for correspondence generation in daily processing whenever possible.

This field holds the version counter used to keep track of the history of an entry of this table. The individual versions are managed by entries in the SLG table.

The purpose of this flag is to mark addresses not to be overwritten by the address download from the host address table. This is also used to check whether an address was manually modified. Any non-empty value protects the database entry from being overwritten by the address import.

Customer number used for addressing DTA messages.

Customer number used for addressing DTE messages.

This field is used to specify the unique ID of the addressee which is used for sending and receiving TradeConnect messages. The TIDTCX has a length of 8 characters.

Number used for addressing of DTG messages.

This field holds the external key of the owning entity group to identify the logical owner of this entry. This field is filled automatically during insert and is used as filter when accessing the database. Without special implementation only entries of the currently active entity group are visible to the user.

May contain a space delimited pattern list of business sectors. If not empty, TCO messages for this address can only be created in the matching business sectors.

May contain a space delimited pattern list of business sectors. If not empty, TCX messages for this address can only be created in the matching business sectors.

This is the full 11-digit Target2-BIC for Target2-Payments. BIC to be used in the message business header to address payments. This BIC is equal to the T2 RTGS Account BIC, except for Multi Addressee BICs.

Usually it is uploaded from the Target2-BIC-Directory.

allNETT customer id Common implementation: Same as DOKA customer id

This flag indicates that an allNETT Id exists and was recently modified. It is used by transaction CONANT to trigger the customer data export to allNETT. Possible values: * Blank: No data export will be triggered * P (Profile): Customer profile data only will be exported to allNETT. This option is defaulted when changing one of these attributes: Name, Address, SWIFT BIC Id, allNETT authorization. * C (Contracts): Full customer data will be exported to allNETT, including profile and contracts. This option is defaulted when setting or modifying the allNETT customer id. CONANT resets this flag after completing the customer data export to allNETT.

This field controls the allNETT customer data entry authorization. Possible values: * I (Inquiry): The allNETT customer has read-only authorization on its data. It is only able to inquire on existing business transactions, but unable to process new transactions. This is the default value. * D (Data Entry): The allNETT customer has read-write authorization on its data. It is able to process business transactions, as well as inquire them.

ANTBUSLST holds a comma separated list of business sectors to which allNETT is restricted for this customer.

If the list is empty and an allNETT ID (ANTID) is set, all sectors are allowed.

Legal Entity Identifier (LEI) is an important (but not mandatory) identifier for ISO.

An LEI is a G20 endorsed, ISO 17442 standard, globally verifiable unique identity code. It is a combination of 20 digit alphanumeric code assigned to a legal entity such as Limited company, Fund or trust or any Organisation. This code allows each entity to be identified on a global database of entities searchable by number instead of by name, as many entities may have similar or the same name.

The LEI has far reaching benefits by increasing transparency within banking, capital markets, KYC, client on-boarding and anti-money laundering.

It should primarily be used as identifier for corporates. For banks the main identifier code should always be a BIC.

BIC indentifying the RTGS “Direct Cash Account” or “Central Bank” Account. BIC is equal to the Addressee BIC except for Multi Addressee BICs.

Currently not used In DOKA. It is necessary if a non-direct T2 RTGS participant would need to debit or credit payments on such a “mirror/nostro” account.

This BIC is usually imported through the T2 RTGS directory.

Main BIC flag in Target2-RTGS.

Usually this information is uploaded from the T2 RTGS directory.

This flag is only shown for information purposes from the T2 RTGS directory.

Main BIC flag is not supported within this application.

In the T2 systems for RTGS payments several types of participation are possilbe:

Direct Participants - 01 - Only Direct Participants have direct access to RTGS. They can provide indirect access to RTGS for other financial institutions and offer them special services. - Direct Particpants are responsible for all money transfer sent and received through their RTGS DCA (direct cash) account.

Indirect Participants - 02 - Indirect Participants don't have an own RTGS DCA (direct cash account) - Indirect Participants are linked to only one RTGS DCA account with a direct participant (could be in another country) - Indirect Participants can be indirectly addressed

Multi-addressee Participants - 03 (Credit Institutions) and 04 (Branch of Direct Participant) - Branch of Direct Participants or Credit Institutions belonging to a 'group' of a Direct Participant. - They are linked through the RTGS DCA account of the Direct Participant. - Their payment orders are settlen on the RTGS DCA account of the Direct Participant.

Addressable BICs - These BICs can only sent and receive RTGS payments through the linked account of a Direct Participant. - Their payment orders are settled on the RTGS DCA account of the Direct Participant.