The account table holds all known account relationships of parties. The account information are identified primarily by the account no. of the servicing party. This is the external commonly known account no. For nostro accounts an additional internal control account no. might be stored for internal book keeping purpose.

The account holder refers to the party which owns the account. On loro accounts this is ussually a client or an other bank. The later case is sometimes called a vostro account. On nostro accounts this is usually the bank itself or a certain branch of the bank.

The account servicing party refers to the party which maintains the accounting system. On loro accounts this is usually the bank itself or a branch. On nostro accounts this is usually the foreign bank.

An ISO term. An account serviced by a bank on behalf of another party (customer / correspondent bank)

Loro accounts are also known as “due to” accounts (due to others)

An ISO term. A record kept by an account owner bank of an account serviced on its behalf by an account servicing bank.

Nostro accounts are also known as the `Due from account'.

An ISO term. A Vostro account has the same meaning as a Loro account!!

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.

If multiple accounts exist, this field can be used to specify the priority sequence in which a particular account may be used for defaulting in the settlement screen. Examples: Main account for L/C's Main account for fees Main account for all automatic settlements

The currency in which the account currently being set up is to be held.

The external key is used to identify the account as unique. The external key can be used to search for an account that is already stored in the database.

This field specifies the account number in the books of the account servicing institution. For all accounts that are maintained at third party instititutions (e.g.: nostro accounts, customer account maintained at another bank etc.).

This field specifies the type of the account servicing institution, and is selected from the list of permitted party types.

The identification number (INR) of the account servicing institution.

This field specifies the optional 'control' account number of the account holder. For example, for a client (loro) account maintained with us, this field may contain the account number in the books of the account holder (client).

This field specifies the (party) type of the account holder. The party type may be selected from the list of defined party types via a combobox.

This field specifies the unique ID under which the account holder is stored in the database.

This field specifies if the account may be used for providing reimbursements under an import letter of credit. Most banks hold a large number of nostro accounts, while not all of theses accounts are eligible for reimbursement authorizations under the import letter of credit. <br/>In order to reduce the number of accounts shown during LC Issuance (when the reimbursement authorization is generated), it is necessary to check this checkbox. Then, on panel reimbursement of the Import LC Issuance transaction (LITOPN) only nostro accounts flagged as reimbursement account are displayed and available as accounts in the outgoing MT740 (Reimbursement Authorisation).

If this field contains a non-empty value, the account is treated as “deleted” and is thus not longer available in account defaulting.

In the Combobox, “X” is used as non-empty value. Thus, if the flag is set by import programs, “X” should be used.

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.

This flag shows if the account can be used for debit, credit, or for both debit and credit bookings.

A non-empty value means that the foreign party has to be treated as a bank in account defaulting.

The name of other party to be used when selecting an account.

A non-empty value means that the foreign party has to be treated as an own party in account defaulting.

If it is an own address, it is set to “A”, if only a branch it is set to “X”

The contents can be reorganized for all accounts using 'Reorganization of Accounts (ACT)'.

This field contains the first six digits of the foreign party for account defaulting. Digits 1 to 4 can be used to check if the BIC is from the same organization. Digits 5 and 6 can be used to compare the country.

The contents can be reorganized via 'Reorganization of Accounts (ACT)' (REOACT) for all accounts.

This field is used to define the International Bank Account Number (IBAN).

This field contains the date when the account was defined for usee use as SEPA account.

he field defines the nature of the SEPA mandate. There are two options - COR and B2B. For further information, please read the SEPA documentation. If the date for the SEPA mandate is filled, this field is mandatory.

This field defines the status of the SEPA account. When the account is first used for an SEPA booking, the value entered has to be FRST (first-time debit), for further use, RCUR (recurring debit). For further information, please read the SEPA documentation. If the date for the SEPA mandate is filled, this field is mandatory.

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.

This field contains a descriptive name (of up to 40 characters) used to identify an account. Searching within a table is usually be done by entering parts of this field. All matches are then displayed to facilitate account selection.

This field defines the external account type.

Each account set up in the system is associated with a specific type, depending on its nature and for which account it is used. Examples are: Vostro Account Nostro Account Letters of Credit Liability Account etc. Each transaction type (Opening a Letter of Credit, Debiting Fees, Settlement of Documents Presented, etc.) is associated with one or more account types so that only the relevant accounts for that transaction are defaulted into the respective transaction panels

This field holds the SEPA mandate ID. The ID can be used for checking external mandate administration

This field holds the no. of days the pre notification must be send in advance

Field holding the concatenated and normalized sum of all search fields used by quick search. This is one of the fields set in a SdbSetNRMFields method defined in the table definition module.