ADR - Address

This table holds all addresses used in contracts. This table is
intended not for direct reference as it might be implemented as a
view into an existing database.
References to ADR entries should be made via a PTA entry.

/

INR

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 ADR. The field INR is used to maintain the standard technical links from other tables (in this case the field OBJINR in the PTA table) into this table.

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.

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.

Long name of the address for display purposes.

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 ISO9362 Business 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 SWIFT messages. The BIC is made up of a maximum of 11 characters or 8 characters for main BICs.

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 S.W.I.F.T 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 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 branch identification (not a SWIFT branch code) indicating location (city). 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 will be 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 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 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 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 . Exception: German BLZ should additionally be entered to the separate field BLZ. Reason: BLZ has been defined in pre-IBAN-times to handle the german Bankleitzahl. When dealing with IBAN account numbers all clearing codes are expected the field CLC.

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.

Identifies the department for communication and correspondence.

This field contains the Email address of the recipient.

This field contains the Email address of the recipient.

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

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 per address can be stored.

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

This field holds the name of the address. Up to 3 name lines are possible. This line is used as first address line in SWIFT messages.

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

This field holds the second line of the name of the address. Up to 3 name lines are possible. This line is used as second address line in SWIFT messages.

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

This field holds the third line name of the address. Up to 3 name lines are possible. This line is used in letters only.

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

This field contains the name of the street and house number of the address. Up to two street lines are possible. This field is used as third address line in SWIFT messages.

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 message.

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

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

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 field contains the name of the city.

This optional field contains the district of the city or additional information on 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 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 for defaulting the preferred method of correspondence for this address.

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

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 contains the ZIP code used when addressing the postbox.

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 text part of the city used when addressing the postbox.

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 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 which is used for sending and receiving TradeConnect messages. The TID has a length of 8 characters.

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 contains the telex number for the recipient.

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

This field is used to control whether telex authentication details are to be displayed in messages details panel.

Permitted values: No = no Telex authentication Yes = Telexes are to be authenticated

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

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

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.

All versions of a master file entry are sequentially numbered in the field VER that is kept in the master file entry. The initial entry starts with the version number zero.

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. Used to check, if an address is manually modified. Any non-blank value protects the database entry from being overwritten by the address import.

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.

Number used for addressing of DTA messages.

Customer number used for addressing DTA messages.

Number used for addressing of DTE 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.

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.

Number used for addressing of DTG messages.

This table is defined on entity group level with separate entries for each entity group. This field holds the EXTKEY of the entity group which is 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 entity group of the currently active entity are visible to the user.

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, 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.

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 field contains the optional ISO bank identifier code (BIC) of the address for the Target2 RTGS Clearing System, which is published in the RTGS Directory by the Euro System (ESMIG) of European Central Bank.

The Target2 RTGS BIC is used to uniquely identify the address in all Target2 messages. The Target2 BIC has always exactly 11 characters. The Target2 BIC can be different from the SWIFT BIC.

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

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 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.

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.

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.

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

The ISO 17442 standard defines the Legal Entity Identifier (LEI). It is a unique 20-character alphanumeric code assigned to all entities that are counterparties to financial transactions. The code itself is neutral, with no embedded intelligence or country codes that could create unnecessary complexity for users.

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

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.

For T2 RTGS this field contains the T2 RTGS BIC which bank is their Target2-account holder with the Euro System (ESMIG) of European Central Bank. For direct T2 participants it is the same BIC as BICTAR.

Usually this information is uploaded from the T2 RTGS directory.

The Target2 BIC has always exactly 11 characters. The Target2 BIC can be different from the SWIFT 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.

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.

Target2 Participation Type

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.