Batch User Guide produced by CRIF - Janata Bank

Userguide Manual 

– Batch Monthly Contribution - 

DRAFT 2.0 

Version of 

September/15/2010

INDEX 

1 REVISION HISTORY __________________________________________ 4 

2 INTRODUCTION _____________________________________________ 6 

2.1 Purpose ______________________________________________________ 6 

2.2 Audience _____________________________________________________ 6 

2.3 GLOSSARY ____________________________________________________ 6 

3 FREQUENTLY ASKED QUESTIONS ON DATA CONTRIBUTIONS __________ 8 

3.1 WHO MUST SEND DATA VIA THE PERIODICAL CONTRIBUTION ___________ 8 

3.2 WHAT IS THE PERIODICITY OF CONTRIBUTION ______________________ 8 

3.3 WHAT DATA MUST BE INCLUDED IN THE CONTRIBUTION _______________ 8 

3.4 WHY SHOULD I SEND REQUESTS __________________________________ 9 

3.5 WHY SHOULD I SEND REFUSED/REJECTED __________________________ 9 

3.6 HOW IS THE INFORMATION CONTRIBUTED __________________________ 9 

3.7 WHAT IS THE SINGLE MOST IMPORTANT THING TO REMEMBER __________ 9 

3.8 ARE THERE ANY SPECIAL CASES THAT REQUIRE A DIFFERENT MANAGEMENT11 

3.9 METHODS OF SENDING MONTHLY DATA ____________________________ 12 

4 INSTRUCTIONS FOR DRAFTING DATA CONTRIBUTIONS _____________ 13 

4.1 CONTRIBUTION FILES __________________________________________ 13 

4.1.1 CONTRACT DATA FILE _______________________________________________ 13 

4.1.2 SUBJECT DATA FILE _________________________________________________ 14 

4.1.3 Type of Link (Roles on a contract) ______________________________________ 15 

4.1.4 ERRORS FILE ______________________________________________________ 16 

4.2 TECHNICAL NOTES _____________________________________________ 16 

4.2.1 FTPS _____________________________________________________________ 17 

4.2.2 CD ROM ___________________________________________________________ 18 

4.3 FORMATS ____________________________________________________ 18 

4.3.1 File format _________________________________________________________ 18 

4.3.2 Date format ________________________________________________________ 18 

4.3.3 Field text format ____________________________________________________ 18 

4.3.4 Mandatory fields ____________________________________________________ 18 

4.3.5 Non-mandatory fields ________________________________________________ 19 

4.4 PHASE FLOWS ________________________________________________ 20 

5 RECORD LAYOUTS __________________________________________ 21 

5.1 SUBJECT DATA FILE ____________________________________________ 21 

5.1.1 SUBJECT DATA FILE RULES ___________________________________________ 22 

5.2 CONTRACT DATA FILE __________________________________________ 34 

5.2.1 SPECIAL NOTES FOR THE REPORTING OF INSTALMENT CONTRACTS ___________ 35 

5.2.2 SPECIAL NOTES FOR THE REPORTING OF CREDIT CARD TYPE CONTRACTS ______ 35 

5.2.3 SPECIAL NOTES FOR THE REPORTING OF NON INSTALMENT CONTRACTS _______ 35 

5.2.4 SPECIAL NOTES FOR THE REPORTING OF LINKS ___________________________ 36 

5.2.5 CONTRACT DATA FILE RULES __________________________________________ 36 

5.3 ERRORS FILE _________________________________________________ 44 

5.4 BATCH DOMAIN TABLES _________________________________________ 45 

5.4.1 TABLE GENDER _____________________________________________________ 45 

5.4.2 TABLE LINK TYPES __________________________________________________ 45 

5.4.3 TABLE CONTRACT PHASES ____________________________________________ 45 

5.4.4 TABLE SUBSIDIZED CREDIT ___________________________________________ 46 

5.4.5 TABLE PREFINANCE OF LOAN __________________________________________ 46 

5.4.6 TABLE REORGANIZED CREDIT _________________________________________ 46 

5.4.7 TABLE PERIODICITY OF PAYMENT ______________________________________ 46 

5.4.8 TABLE TYPE OF INSTALMENT __________________________________________ 47 

5.4.9 TABLE CARD USED IN THE MONTH______________________________________ 47 

5.4.10 TABLE TYPES OF LEASED GOOD ______________________________________ 47 

5.4.11 TABLE TYPES OF LEASED GOOD – FLAG NEW/USED ______________________ 47 

5.4.12 TABLE METHOD OF PAYMENT ________________________________________ 48 

5.4.13 TABLE PERSONAL GUARANTEE TYPE ___________________________________ 48 

2 of 92

5.4.14 TABLE REAL GUARANTEE TYPE _______________________________________ 48 

5.4.15 TABLE ID ________________________________________________________ 49 

5.4.16 TABLE SHAREHOLDERS TYPES _______________________________________ 49 

5.4.17 TABLE SECTOR TYPES ______________________________________________ 49 

5.4.18 TABLE SECTOR CODE ______________________________________________ 50 

5.4.19 TABLE LEGAL FORMS _______________________________________________ 55 

5.4.20 TABLE CONTRACT STATUS __________________________________________ 55 

5.4.21 TABLE CONTRACT TYPE _____________________________________________ 56 

5.4.22 TABLE ECONOMIC PURPOSE _________________________________________ 57 

5.4.23 TABLE COUNTRY CODES ____________________________________________ 61 

5.4.24 TABLE CURRENCY CODES ___________________________________________ 66 

5.4.25 TABLE DISTRICTS _________________________________________________ 70 

5.4.26 TABLE ERRORS ___________________________________________________ 71 

5.5 BATCH EXAMPLE FILES _________________________________________ 77 

5.5.1 BATCH EXAMPLE FILES - Structure ______________________________________ 78 

5.5.2 BATCH EXAMPLE FILES - Data _________________________________________ 78 

6 SPECIAL CASES AND EXCEPTIONS ______________________________ 84 

6.1 Changes to Subjects linked to a Contract ___________________________ 84 

6.2 Renounced/Refused credit applications ____________________________ 84 

6.3 SPECIAL CASES FOR INSTALMENT CONTRACTS _______________________ 84 

6.3.1 Contract with split and/or postponed drawdown ___________________________ 84 

6.3.2 Contract with the first installment due date after the credit drawdown __________ 85 

6.3.3 Mortgages splitting __________________________________________________ 85 

6.3.4 Irregular payment behaviour __________________________________________ 85 

6.4 CREDIT REORGANIZATION (also known as RESTRUCTURING) ___________ 88 

6.4.1 Credit is reorganized while maintaining the same FI Contract code _____________ 88 

6.4.2 Credit reorganization without creating a new contract _______________________ 90 

6.4.3 Credit restructuring through the direct opening of a new credit line ____________ 91 

6.5 RE-OPENING OF TERMINATED/TERMINATED IN ADVANCE LOANS ________ 92 

3 of 92

1 REVISION HISTORY 

Release 

Date 

Version 

No. 

Description 

20/05/2010 1.0 Release of document. The document integrates the files 

structure provided during training. To that document following 

changes have been done: 

- implemented validation of sector code; 

- added domain for sector code 

- updated Personal/Real guarantee domain 

- added domain of Economic purpose 

- added domain validation of Economic purpose 

- added value 2 in Table Re-Organized Credit 

- added 3 new Countries in Table Country Codes 

- deleted value A in Table Link Types 

- deleted Table Insolvency 

30/06/2010 1.1 Cards – specification of how to set credit limit when the card is 

unlimited. 

Field National ID Number avaliable/not available – 

specification of how to correctly value the field. 

FI code – specification of how to set codes with less than 3 

characters. 

Non instalment contracts description. 

23/07/2010 1.2 Changed label „Document‟ with „ID‟ for congruence reasons. 

Added Cash in Table Method of payment. 

Changed label „Number of Instalments‟ in „Total Number of 

Instalments‟ for congruence reasons. 

Section 4.1.1: changed June 31st with June 30th (text and 

graphs) 

Section 4.2 corrected „three methods‟ with „two methods‟ 

Decription of field „Overdue not Paid Amount‟: the description 

has been corrected. 

Encoding – changed encoding windows 1252 in UTF-8 to solve 

some characters interpretation problems found in some 

Institutes files and as noted by Institutes. 

Flag re-organized credit: exchanged value 1 and 2 

Section 4.1.1: corrected incongruity on dates in the example. 

Section 6.4.1: Changed Eurisc with Credit Bureau as 

suggested by some Institutes. 

Section 6.2: Corrected inconsistent definition of 

renounced/refused. 

Changed label „Flag Reorganized Credit‟ to „Code Reorganized 

Credit‟. 

Added section 5.2.5 for consistency 

Corrected N(3)/N(3)/N(4)T with N(3)/N(3)/N(4) 

Nr. Of records – added note 

Added paragraph with list of errors of check and update 

phase. 

Added chapter with example files section 5.5 

15/09/2010 2.0 Reinforced paragraph 3.8 

Changed order of paragraphs, putting “exceptions” at the end 

of the document and therefore rendering the logical 

progression of sections more intuitive and less confusing, as 

requested by some Institutions. 

4 of 92

Added section 5.2.1, 5.2.3, and 5.2.4 and moved 5.2.2 next 

to them as it flows better logically. 

Removed references to CRIF in sections 3.3, 3.6, 4.1.3, 6.2, 

6.4.2 

Heavily revised section 6.4 to make it clearer. 

Added sections 3.4 and 3.5 

Clarified section 6.3.4 

Added description of errors file and they structure. 

Attached contribution examples files. 

Added list of errors after pre-check phase 

Added specification of .zip file that groups the Errors files. 

Added indication of communicate to CIB that the file 

contribution has been sent 

5 of 92

2 INTRODUCTION 

2.1 Purpose 

The current user guide is a tool for users of the online Credit Bureau system at Bangladesh Bank 

(the System from now on). Specifically, the user guide details the key processes needed for the 

monthly contribution. 

There are essentially two different kinds of interaction between users and the System: Online 

and Batch. 

The Online interaction is accessed by users of the system (Banks and Non-Banking Financial 

Institutions) to: 

a) Notify CIB of a new request for Credit that your institution received from a client and/or 

b) To update some attributes of a credit request and/or 

c) To retrieve a credit history on a Client of your institution 

The Batch interaction, instead, is used by users of the system to communicate, on a periodical 

basis, relevant information on its Clients and their financial obligations at the institution. 

The two interactions are quite different, in terms of what they are meant to achieve, how they 

are carried out and who within your institutions will need to be trained on it. For this reason we 

are providing separate user guides for the Online and Batch components. 

The current user guide is for the BATCH component. 

It is not meant as a comprehensive, all inclusive resource, but as a first document of reference 

for the most common needs of the user. 

For any questions or comments, please contact the contribution support team via email at 

mehedi.hasan@bangladeshbank.org, or via phone number at 7126101-20/3045 

2.2 Audience 

All Banking and Non-Banking Financial Institutions regulated by Bank of Bangladesh are 

mandated to contribute to the System. This user guide is therefore aimed at the technical team 

of each institution that is responsible for implementing the regular contribution of data to the 

System. 

2.3 GLOSSARY 

Below are definitions of some important terms used in this document: 

Financial Institution (FI) - User: the terms are used interchangeably to mean the bank or 

non-banking financial institution that is regulated by the Bangladesh Bank and must therefore 

send monthly data updates to the credit bureau. 

Client: a customer of the FI that has requested a new credit relationship with such FI or who 

already has a credit relationship with them, including any related Co-Borrowers, Guarantors, and 

Owners/Shareholders of Companies. 

Consumer - Individual: an individual who has requested or obtained credit 

Non-Consumer: a Sole Trader or a Company who has requested or obtained credit 

Contract – Account - Credit Line Data: terms used intercheangebly to identify the dataset of 

„financial and other information‟ relating to a credit relationship 

Subject - Client Data: the dataset of „personal information‟ relating to an interested party – 

this includes information on Consumers and Non-Consumers. 

6 of 92

New Credit Line Data – New Contract: Credit Line Data that is sent for the first time in a 

monthly contribution (a credit line application that has already been entered via an online 

enquiry must also be sent as a new credit line). 

New Client Data – New Subject: Client Data that is sent for the first time in a monthly 

contribution for a Data Client in a given credit relationship. A Client may have already been sent 

within a contribution, linked to other Credit Line Data, so it not necessary re-send again the 

client dataset. It is necessary fill in the link (into the proper field of layout contribution file) with 

the New Credit Line. 

Contract (or Subject) Data Update: a data update pertaining to a Contract (or Subject) where 

data has already been sent by means of a monthly contribution. 

Mandatory Field: This field must be completed. Failure to do so will result in an error being 

reported by the System. 

Dependent Field: This field must be completed in specific circumstances indicated in the guide. 

Optional Field: The FI can decide whether or not to complete this field. 

Borrower: The Subject requesting or having been granted credit. Each Contract must have 

associetad with it one and only one Borrower. If there are multiple borrowers, one is identified as 

the Borrower, all others are identified as Co-Borrowers. 

Co-Borrower: In a case with multiple borrowers that share the level of risk of a Contract, one is 

identified as the Borrower, all others as Co-Borrowers. From the standpoint of level of credit risk 

there is no difference between a Borrower and related Co-Borrowers in the System. Each 

Contract can have from “0” to “n” Co-Borrowers. 

Guarantor: A Subject that places a guarantee in whole or in part, with personal or real 

guarantees, on a specific Contract requested by or issued to a specific Borrower. 

Credit Request – Requested Credit: A request for credit issued by a Client 

Renounced Credit: The Client is no longer interested in a Credit Request previously placed at 

the FI 

Refused Credit: The FI refused a specific Credit Request of a Client 

Living Credit: The FI agreed to provide credit to a Client following a specific Credit Request, and 

the Client agreed to the terms proposed by the FI 

Terminated Credit: the specific Contract has been closed (whether because fully repaid or for 

whatever reason) on, or after the expected closing date. No further information on the Contract 

will be sent by the institution after the contribution in which is declares a Contract to be 

Terminated Credit. 

Terminated in Advance: the specific Contract has been closed (whether because fully repaid or 

for whatever reason) before the expected closing date. No further information on the Contract 

will be sent by the institution after the contribution in which is declares a Contract to be 

Terminated in Advance. 

Owner: A subject with a special role in a company as those indicated in table 5.4.16, or also the 

individual that owns a Proprietorship. 

Individuals: with term “individual” we refer to an actual person 

Sole Trader or Sole Interest or Individual Concern or Proprietorship or Proprietorial 

Concern: with term “sole trader” we refer to a type of business entity which legally has no 

separate existence from its owner. All debts of the business are debts of the owner. The person 

who sets up the company has sole responsibility for the company's debts. It is a "sole" trader in 

the sense that the owner has no partners. A sole trader essentially refers to a natural person 

(individual) doing business in his or her own name and in which there is only one owner. A sole 

trader may do business with a trade name other than his or her legal name. 

Company: with the term “company” we refer indifferently to 

a form of body corporate or corporation, generally registered under the Companies Acts or 

similar legislation 

every Business Institutions, Government and Semi-government organizations, Industries 

It does not include a partnership or any other unincorporated group of persons. 

7 of 92

3 FREQUENTLY ASKED QUESTIONS ON DATA 

CONTRIBUTIONS 

3.1 WHO MUST SEND DATA VIA THE PERIODICAL CONTRIBUTION 

As indicated above, all FIs regulated by Bangladesh Bank must contribute to the periodical 

contribution. 

Please note, only one contribution per FI is accepted. FIs with multiple branches, therefore, must 

collect and compile information from all branches, and provide a unified contribution each month. 

3.2 WHAT IS THE PERIODICITY OF CONTRIBUTION 

The batch contribution must be sent monthly. All data for each month must be sent by the 20 th 

of the following month, regardless of holidays and bank closing. While the deadline is the 20 th , 

Banks and FIs, however, should try their best to send the data as early as possible in the month 

(by the 5 th should be ideal). The earlier the data is sent, the more updated is the database, and 

the more valuable is the information for banks themselves. 

3.3 WHAT DATA MUST BE INCLUDED IN THE CONTRIBUTION 

The FI must send the following information to CIB during each contribution: 

 

 

 

 

 

SUBJECT DATA: data relating to ALL Borrowers, Co-Borrowers or Guarantors (irrespective of 

whether they are Individuals, Sole Interests, or Companies) for whom a contract over the 

threshold (please see below) has been granted in the previous month (if the client data 

have been never sent in previous contribution); data pertaining to Owners/Shareholders 

of any of these subjects; and data related to links between Companies and their 

Owners/Shareholder contributed. 

CONTRACT DATA: data relating to all new contracts Granted, Refused or Renounced in the 

course of the month prior to the monthly contribution where the total financed amount (for 

instalment contracts) or the total Credit Limit (for credit cards and non instalment contracts) 

are above 50,000 Thaka; as well as Link information between each Contract and the 

Borrower, eventual Co-Borrowers, and eventual Guarantors; as well as Score information on 

specific Subjects; 

SUBJECT DATA UPDATE: data relating to any Subject already sent in previous monthly 

contributions that have since changed. In this case it is necessary to send all the Subject 

data and not only the modifications; 

CONTRACT DATA UPDATE: data relating to all Living Contracts in the Bank‟s portfolio in the 

preceding month, or those acquired from other FIs, where the total financed amount (for 

instalment contracts) or the total Credit Limit (for credit cards and non instalment contracts) 

are above 50,000 Thaka;. All Contract Data and not only the changes from the previous 

must be sent. The FI must send an update of the contractual data every month, whether 

such data has changed or not. 

CONTRACT CLOSING: data relating to all Contracts that were closed (whether closed on time 

as expected, or closed in advance) in the preceding month. All Contract Data and not only 

the changes in status must be sent. 

The types of credit lines for which data must be sent to CIB are detailed in table 5.4.21. 

8 of 92

3.4 WHY SHOULD I SEND REQUESTS 

One of the strenghts of the system is that it does not only report unpaid amounts (which can be 

used to assess existing credit risk) nor does it only report granted amounts (which can be used 

to access potential credit risk), but also usage and requests, which can be used to assess risk of 

over-exposure. By submitted requested credit, the system also insures that if someone goes to 

three institutions the same day to ask credit, they don‟t all provide it without knowing the same 

credit has been requested elsewhere. 

3.5 WHY SHOULD I SEND REFUSED/REJECTED 

We saw in 3.4 how credit requests can be used to assess over-exposure risk. By the same token, 

once a credit request is refused or rejected, such risk is no longer real. It is good practice, 

therefore, to provide the notification of refused/rejected credit to keep the credit history up to 

date. 

It is understandable, however, that not all institutions are immediately equipped to perform this 

notification. Therefore the system is set to automatically archive open requests after one year. 

3.6 HOW IS THE INFORMATION CONTRIBUTED 

While we have a specific paragraph (please see section 4.2) that details the technical 

specifications of how the information is sent, at the very high level please note that each 

contributor must send, with each contribution, 2 separate files. 

1) A file containing Subject information 

2) A file containing Contract information 

Each file will be a space delimited .txt file with the structure defined in section 5 

3.7 WHAT IS THE SINGLE MOST IMPORTANT THING TO REMEMBER 

The key aspect to keep in mind is that each contributing institution must be able to manage 

internally a unique identification code that refers explicitly to a single subject as well as a unique 

identification code that refers explicitly to a single contract. Neither of these number is the CIB 

Borrower Code that existed in the previous system. 

CIB Code and FI Contract/Subject code Definition 

Every Subject and Contract record contributed (online or batch) to the system needs to be 

uniquely identified. This is achieved by assigning an unique code to each record. Codes are 

divided into two groups: User and CIB. 

FI codes – (FI Subject code or FI Contract code) are those codes contributed by the User. 

These codes either generate new entries in the database (if the system does not 

recognize the information as already present within the DB) or are linked to already 

existing information. FI codes must be always 

unique for a given FI. 

CIB codes – sometimes also referred as DB 

codes - (CIB Subject code or CIB Contract code) 

are unique codes at the system level. These 

codes are used to group the identical 

information contributed by different FIs 

9 of 92

(therefore more than one FI code) under the same code. 

Please note : each FI will provide its own FI ID for a specific Subject. This naturally means, that, 

if the same Subject is a client of more than one FI, they will have multiple FIs providing codes to 

the System. This is perfectly fine, as the System will recognize the Subject as the same, and 

remember the unique codes that each FI use to identify that Subject, as well as assign a unique 

CB code that does not change depending on the FI (see graphical example to the right). 

By the same token, an FI with multiple branches might not able to recognize the same Subject 

across different branches, therefore in the monthly contribution, it could occur that the SAME 

Subject is contributed more than one times with DIFFERENT FI ids. While this should be avoided 

if possible, the System will be able in most cases to recognize the Subject as the same subject, 

and remember all the unique codes that the specific FI uses to identify that Subject (see 

graphical example below). 

What is EXTREMELY important is to remember that, while the same Subject can have more than 

one FI ID, two DIFFERENT subjects CANNOT have the SAME unique ID number. In the case of 

multiple Borrowers on the same Contract, each Borrower is a separate Subject, and one is 

indicated as the Borrower, the second as the Co-Borrower. 

In the case of Contract unique ID, since each contract can belong only to one FI (and to one 

branch of the FI), there will always be one and only one FI ID for each contract. There cannot be 

multiple FIs reporting on the same contract (by default), nor multiple FI Id numbers for the same 

contract. 

Let‟s spend a moment to be clear on what is a Contract, and the related Unique ID. Let‟s say Md. 

Shafiqul Islam is a client of the institution FI1. Let‟s say in FI1, he has a checking account, an 

overdraft protection on the checking account, and a term loan. In this case, the checking account 

is not a form of credit from the bank to the Subject and therefore is NOT a contract in our sense. 

The overdraft protection, however, is a form of credit. Therefore it is a Contract in our definition, 

and it is given a unique code (let‟s say 112). The term loan is another Contract. Even though it 

refers to the same Subject with the same FI, it is a separate loan and therefore has its own 

unique code (let‟s say 251). 

10 of 92

Therefore, please make sure that even if they belong to the same Subject at the same 

institution, each Contract must have its own, separate code. 

It is also important to note that FI‟s must contribute only the current month‟s situation of their 

contracts. It is the system itself that compiles automatically the history with each monthly 

contribution. 

It is of fundamental importance that the data relating to all Subjects (whether borrowers, coborrowers, 

or guarantors) and credit lines are sent to CIB together with the bank or financial 

institution‟s unique codes (e.g. subject identification code or contract identification code). This 

allows the authorized employees of the bank or financial institution to gain access to their 

customers‟ records in the CIB credit reporting system using the lending institution‟s own internal 

codes. 

Furthermore, these are the codes that allow each contract in the contract file to be connected to 

the appropriate subjects in the subject file. 

It is also important to note that three different types of borrower/guarantor are allowed: 

Value 

Description 

1 Individuals 

2 Sole Trader 

3 Companies 

The correct identification as Individual, Sole Trader and Company must be made when sending 

data to CIB via batch, and when making online enquiries about new credit line applications. 

3.8 ARE THERE ANY SPECIAL CASES THAT REQUIRE A DIFFERENT 

MANAGEMENT 

Yes there are. However, we strongly suggest that users familiarize themselves with the rest of 

the document (section 6) that deals with the usual cases first, and only deal with these special 

cases when needed, as they are mostly exceptions. Without a clear understanding of the rest of 

the document, otherwise, this section will appear quite confusing to most readers. For this 

reason, we have put these special cases as an addendum at the end of this guide. 

11 of 92

3.9 METHODS OF SENDING MONTHLY DATA 

MONTHLY CONTRIBUTION: 

The SUBSCRIBER must ensure that the monthly contribution reaches CIB by the 20 th of every 

month, sending data relating to the previous month (e.g. for 20 th July, the data refer to the 

month up to the 30 th June). 

For technical details regarding the contribution please refer to section 4.2 

12 of 92

4 INSTRUCTIONS FOR DRAFTING DATA CONTRIBUTIONS 

4.1 CONTRIBUTION FILES 

The data contribution must include the following two separate files with the specified information 

every month: a Contract Data file and a Subject Data file. 

4.1.1 CONTRACT DATA FILE 

It is a single Contract Data file, which contains: 

o all Contracts (installment, non installment, credit card and revolving credit 

operations) that were Approved, Refused or Renounced in the reference month. 

o all existing (living) Contracts that were reported in the previous month or in 

previous months. PLEASE NOTE: 

• even if nothing has changed in the contract, once a contract is existing 

(living), all the relevant information must be sent each month. 

o all Contracts that terminated (i.e. were closed) during the reference month, 

whether these contracts were closed at the natural end of the contract (closed), or 

were terminated prior to the natural and expected end of the contract for whatever 

reason (closed in advance). For example, an Instalment Loan that was fully 

repayed on time will be closed. An Instalment Loan that was fully repayed months 

before it expired is closed in advance. The same goes for Non-Instalment loans. 

o Y score, Z score, and Grading (optional) 

o all links that indicate for each Contract, any new Co-Borrower or Guarantor. 

PLEASE NOTE: 

• Each contract can have one and only one Borrower, identified via the FI 

Subject code. 

• Co-Borrowers and Guarantors are provided as specific links. 

• Please refer to section 4.1.3 for further information. 

It follows from the above indications that the Contract Data file WILL NOT contain: 

o open requests, that is those that have not yet been Approved, Refused or 

Renounced yet. These are reported via the online channel, not the batch channel 

o requests that were Refused or Renounced in previous months, and for which a 

contribution indicating status as Refused or Renounced has already been provided. 

For the sake of clarity, let‟s say a Subject “A” provides a request to Bank 1 for 

credit on May 1 st . The Bank provides an online enquiry that automatically writes 

the Request to the System via the online channel. On June 10 th the bank Refuses 

the request. Therefore in the May contribution (which must be sent to CIB by June 

20 th , and in our example is sent on June 5 th ) no info is provided via batch on the 

Request. In the June contribution (which must be sent to CIB by July 20 th , and in 

our example is sent on July 5 th ) Bank 1 will update the request as Refused. In the 

July contribution (which must be sent to CIB by August 20 th , and in our example is 

sent on August 5 th ) Bank 1 will no longer report any information on the Refused 

request. 

o contracts that were Closed or Closed in advance in previous months, and for which 

a contribution indicating status as Closed or Closed in advance has already been 

provided. For the sake of clarity, let‟s say a Subject “A” has an existing Contract at 

Bank 1 for credit set to expire on June 30 th which is repayed in full and on time. 

Therefore in the May contribution (which must be sent to CIB by June 20 th , and in 

our example is sent on June 5 th ) the Contract Data is regularly sent to CIB as the 

contract is ongoing. In the June contribution (which must be sent to CIB by July 

20 th , and in our example is sent on July 5 th ) Bank 1 will update the Contract status 

as Closed. In the July contribution (which must be sent to CIB by August 20 th , and 

in our example is sent on August 5 th ) Bank 1 will no longer report any information 

on the Contract. 

13 of 92

The following graphical representation shows the situation in the database of a Bank on May 1 st , 

how the situation changes on May 31 st , what this means for the contribution on June 5 th , then 

assumes no changed in the month of June, and shows the contribution for July 5 th , according to 

the indications provided above. 

4.1.2 SUBJECT DATA FILE 

It is a single Subject Data file, which contains: 

o all Subject information for individuals, sole traders (and their owners), or 

companies linked to contracts (i.e. Subjects that are Borrowers, Co-Borrowers, or 

Guarantors on any such contract) that were approved, refused or renounced in the 

reference month unless they had been sent before. For example, if Subject “A” is 

the Guarantor on a contract “X” that is being contributed in the Contract Data file, 

his data must be contributed with the same monthly contribution in the Subject 

Data file. If months later he is a Co-Borrower on another contract, his data need 

not be sent again. 

o all Subject Data for individuals, sole traders, or companies previously contributed 

and for which any of the fields have changed in the reference month. For example, 

if Subject “B” had been contributed in the past and in the last month he changed 

his address and communicated this information to his bank, that bank must 

provide the full Subject data file, with the new address, in the Subject Data file of 

the monthly contribution. 

o Links between “owners” and Companies. “Owners” are defined as Individuals with 

a special role in a company according to the table 5.4.16. These must be 

contributed at least once. After the first contribution they can continue to be 

contributed but it is not necessary. Should any additional “Owner” need to be 

added to a contributed company, they must be contributed. In order to remove the 

link between one or more “Owners” and a specific Company, you need to contact 

CIB. 

o Please note: 

• The very first contribution will include ALL Subjects for which Contracts are 

being contributed to populate correctly the CIB database 

The following graphical representation shows the situation in the database of a Bank on May 1 st , 

how the situation changes on May 31 st , what this means for the contribution on June 5 th , then 

14 of 92

assumes some changes in the month of June, and shows the contribution for July 5 th , according 

to the indications provided above. Please note, as stated above, contributions must be sent by 

the 20 th of each month, but early contribution (such as by the 5 th ) should be attempted 

whenever possible. 

4.1.3 Type of Link (Roles on a contract) 

The data records of all the Subjects related to a credit line must be sent to CIB, and a role on 

said Contract must be assigned to each Subject (also known as Type of Link). CIB carries out 

consistency checks on the Subjcets linked to the Contacts based on the following information: 

 

 

 

 

if the Contract has one and only one Borrower WITH DIRECT RISK, that Subject is attributed 

the role of BORROWER. Any eventual Guarantors associated with the Contract will be 

contributed with role GUARANTOR. In this case there are no Co-Borrowers (since we said 

there is only one subject with direct risk). The FI Subject Code of the BORROWER must be 

sent (from column 9 to column 24 in Contract data - Body for Record Type: General 

information for all types of Financing) whenever the contract is sent. During the life of 

contract, the subject code can never change. 

if there is more than one client involved in the Contract as Borrower WITH DIRECT RISK, one 

will be assigned the role of BORROWER, the others will be assigned the role of CO- 

BORROWERS. As in the previous case there can also be GUARANTORS. 

GUARANTOR clients are those which provide guarantees for the Contract. Please refer to 

tables 5.4.13 and 5.4.14 

CO-BORROWERS and GUARANTORS links must be provided through the CONTRACT DATA 

FILES – Body for Record Type: contract Links. all Co-Borrower and all Guarantor links must 

be provided with the first available contribution. After that, providing them again is not 

necessary but will not cause an error as long as they are the same. Should new Subjects be 

added to the contract, you must provide their role. Instead if you want to remove existing 

Subjects with role on a contract, this cannot be done automatically but must be done by 

contacting CIB. 

15 of 92

4.1.4 ERRORS FILE 

Both subject and contract batch files will be processed by the system in 3 separate rounds of 

checks that allow a deeper quality control; the first step called Pre-Check phase simply looks at 

the structure of the files, i.e. it ensures that the file being send is correctly formed. If there is an 

error at this level, the whole contribution will be discarded. CIB will then contact the Institutions 

with suggestions on how to fix the error(s). 

The second step called Check phase performs a series of in-depth checks, while the final step 

called Acquisition performs specific checks and loads the data in the CB production environment. 

The Check and Acquisition phases can be further divided in 3 sub-steps: one for subjects, one for 

contracts and one for links as follows: 

Check Phase 

o Check for subjects (CTA) – all records of Individual, Proprietorship and Company 

that are in the subject file are checked in this step. 

o Check for contracts (CTC) – all records of Instalment, Non Instalment, Cards that 

are in the contract file are checked in this step 

o Check for links (CTL) – all records of Company shareholders that are in subjects 

file and all records of Subject information and Links that are in the contract file are 

checked in this step 

Acquisition Phase 

o Check and loading for subjects (ACA) – all records of Individual, Proprietorship and 

Company that are in the subject file are re-checked, checked against data in the 

DB, and loaded in this step 

o Check and loading for contracts (ACC) – all records of Instalment, Non Instalment, 

Cards that are in the contract file are re-checked, checked against data in the DB, 

and loaded in this step 

o Check and loading for links (ACL) – all records of Company shareholders that are 

in subjects file and all records of Subject information and Links that are in the 

contract file are re-checked, checked against data in the DB, and loaded in this 

step 

If the files sent by the institution have good quality and the number of errors after the Check 

phase is not particulary high, CIB will continue with the Acquisition Phase; any errors identified 

at the end of the Acquisition phase will be written in some specific files and sent to Institutes. If 

no errors are present, empty errors files are produced in any case (with only the name of 

columns). 

If the files sent by the institution have poor quality and the number of errors after the Check 

phase is too high to proceed with the Acquisition phase, CIB will not proceed with the Acquisition 

Phase, but rather return to the Institution some specific files that provide the list of errors 

identified by the Check Phase. 

The Credit Bureau provides 2 types of errors files: 

One type of file (called error file) containing the complete list of all errors occurred during 

the specific Phase (Check or Acquisition) 

Onother type of file (called error summary) containing the total number of occurrencies 

for each kind of error 

4.2 TECHNICAL NOTES 

The data (input files) must be sent by one of two methods, as agreed bilaterally by each FI with 

CIB: 

1) FTPS transmission 

2) CD Rom submission 

CIB will use the same method to send back to the Institution the errors files (output files see 

4.1.4). 

16 of 92

4.2.1 FTPS 

The monthly contribution files have to be transmitted via FTPS to ftps://ftp.bbcib.org.bd; the 

name of folder for input files is MONTHLYIN. 

The filenames for input files must follows this format: 

FILE 

Credit Line Data 

Client Data 

File name 

XXXCNF.txt 

XXXSJF.txt 

Please note: “XXX” must be replaced with the FI code. 

The two input files must have UTF-8 encoding. The couple of file must be zipped, and the 

resulting zipped archive must have the same date of production used in its file names. The same 

production date must be also placed in the header and footer of each file. This rule is applied to 

ensure that both files refer to the same batch. The contribution batch is rejected if this rule is not 

met. 

Therefore the resulting zip file will have the following name: 

yyyymmdd_XXX.zip 

where yyyymmdd must be replaced by the production date of the file (which must be the same 

that is provided within the two files), while “XXX” must be replaced by the FI code. 

PLEASE NOTE: after sending the file in the FTP folder, you must also send an email to 

mehedi.hasan@bangladeshbank.org to indicate that the file was sent. 

If the input file is sent by the institution through the FTPS protocol, CIB will return the output 

files to the Institution with the same protocol; the name of folder for output files is 

MONTHLYOUT. 

The filenames for output files follow this format: 

FILE File name Notes 

File of errors after step 

ACA 

File of Errors summary 

after step ACA 


ACC 


after step ACC 


ACL 


after step ACL 


CTA 


after step CTA 


CTC 


after step CTC 

XXX_ddmmyyyy_ACA_Errors.txt 

XXX_ddmmyyyy_ACA_ErrorSummary.txt 

XXX_ddmmyyyy_ACC_Errors.txt 

XXX_ddmmyyyy_ACC_ErrorSummary.txt 

XXX_ddmmyyyy_ACL_Errors.txt 

XXX_ddmmyyyy_ACL_ErrorSummary.txt 

XXX_ddmmyyyy_CTA_Errors.txt 

XXX_ddmmyyyy_CTA_ErrorSummary.txt 

XXX_ddmmyyyy_CTC_Errors.txt 

XXX_ddmmyyyy_CTC_ErrorSummary.txt 

Always produced 






Produced only in case 

of poor contributions 







17 of 92


CTL 


after step CTL 

XXX_ddmmyyyy_CTL_Errors.txt 

XXX_ddmmyyyy_CTL_ErrorSummary.txt 





Please note: “XXX” each time will be replaced with the FI code of your institution and ddmmyyyy 

will be replaced with the Accounting Date of the file being sent. 

In the FTP folder the errors files will be grouped in a .zip file with the following name convention: 

XXX_ddmmyyyy_dd_MM_yyyy_HH_mm_ss where: 

XXX is the FI code 

ddmmyyyy is the Accounting Date of the file 

dd_MM_yyyy_HH_mm_ss is the timestamp that indicates when the file has been put in 

FTP folder 

There are many clients available on the market (some for free). Our users have had success with 

specific versions of Filezilla. CIB will communicate the suggested FTP transfer client after tests in 

production determine the best performing one. 

4.2.2 CD ROM 

If the FTPS channel is unavailable to the FI, the monthly contribution files can be transmitted 

encrypted via CD Rom. 

The filenames must follow the same format as the FTPS submission. 

PLEASE NOTE: after sending the CD ROM, you must also send an email to 

mehedi.hasan@bangladeshbank.org to indicate that the file was sent. 

4.3 FORMATS 

4.3.1 File format 

The input file type must be a space delimited .txt file, and must have UTF-8 encoding. 

The output file type is a space delimited .txt file where the first row shows the name of the 

column. 

4.3.2 Date format 

Dates within the contribution files must be sent in the format DDMMYYYY without spaces or other 

dividing characters. 

4.3.3 Field text format 

The field text must be entered in CAPITALS. 

4.3.4 Mandatory fields 

When filling out Mandatory fields, the information to be inputted will not always be exactly the 

length of the field. Therefore the following characters should be used to fill the fields: 

for Numeric Fields: left padded with ZEROs to fill the length of the field. For example, if a 

Numeric Field has size “8”, and we want to show the number “1,000” we will need to fill it 

with the number between the following quotation marks “00001000”; 

18 of 92

for Alphanumeric Fields: right padded with BLANKs to fill the length of the field. For 

example, if an AlphaNumeric Field has size “8”, and we want to show the text “closed” we 

will need to fill it with the text between quotation marks “CLOSED ”, which is the word 

that we want, followed by 2 separate spaces; 

for Date Fields: left padded with ZEROs to fill the length of the field. For example, if a 

Date Field has size “8” and we want to show the date “6 June, 2010” we will need to fill it 

with the number between quotation marks “06062010”; 

unless specific instructions are given within the field in the attached tables. 

4.3.5 Non-mandatory fields 

If the Optional or Dependent fields are not filled out, they cannot be left “NULL”. Therefore the 

following characters must be used to fill the fields: 

for Numeric Fields: left padded with ZEROs to fill the length of the field. For example, if a 

Numeric Field has size “8” we will need to fill it with the number between quotation marks 

“00000000”; 

for Alphanumeric Fields: right padded with BLANKs to fill the length of the field. For 

example, if an AlphaNumeric Field has size “8” we will need to fill it with the text between 

quotation marks “ ”, which are 8 separate spaces; 

for Date Fields: left padded with ZEROs to fill the length of the field. For example, if a 

Date Field has size “8” we will need to fill it with the number between quotation marks 

“00000000”; 

unless specific instructions are given within the fields in the attached tables. 

19 of 92

4.4 PHASE FLOWS 

RQ 

RN 

RF 

Monthly contribution 

begins. Possible following 

phases are: 

The contract will be 

“LV” until its 

closure. 

LV 

RN 

RF 

TM 

TA 

Legend: 

This phase refers to online updates (new contract enquiry). 

This phase refers to batch updates (monthly contribution). 

Notes: 

Contracts in RQ phase theoretically can be contributed also in monthly batches. 

However, since all the compulsory fields have to be filled in this case as well, it is 

not recommended to use the RQ phase in batch files unless the FI has complete 

and accurate information from a customer. 

20 of 92

Table – Country Code 

This list states the country names (official short names in ENGLISH) in alphabetical order as 

given in ISO 3166-1 with the addition of some historical country names, and the corresponding 

ISO 3166-1-Alpha-2 code elements. For the complete listing of available values please refer to 

table 5.4.23. 

Table – Currency Code 

This list states the country currencies (official short names in ENGLISH) in alphabetical order as 

given in ISO 4217. 

For the complete listing of available values please refer to table 5.4.24. 

5 RECORD LAYOUTS 

As we have seen in the following sections the monthly contribution contains both a Subject Data 

file and a Contract Data file. We will examine each in turn. 

Please refer to section 3.6 for the technical rules of completing the fields. 

5.1 SUBJECT DATA FILE 

The Subject Data File is a continuous, space delimited .txt file that has between 2 and 9.999.999 

rows of information. 

The first row (and only the first row) will ALWAYS be the Header. Please refer to table 5.1.1 for 

the rules to fill the header row. 

The last row (and only the last row) will ALWAYS be the Footer. Please refer to Annex 5.1.1 for 

the rules to fill the footer row. 

In between the header and the footer, there will be a varying number of lines, each carrying 

different sets of information. 

ALL rows (including the Header and the Footer) will ALWAYS be 1100 

characters long, but the composition of each row depends on the type 

of information that is being provided in that particular line. 

Specifically, the type of information that the Subject Data file provides 

are the following: 

• 0 to “n” rows of 1100 chars each of identification information of 

Individuals as well as 


Sole Proprietorships as well as 


Companies as well as 

• 0 to “n” rows of 1100 chars each of information that links 

specific individuals to specific companies as owners 

Depending on which of the above information a particular row contains, 

different rules must be used to fill out such row. Therefore if a 

particular row contains Individual information, for example, the 

instruction provided in “Body for Record Type: Personal Data” of 5.1.1 

need to be followed. Conversely if the information in the row is a link 

between owners and companies, the row must be filled out according to the rules in “Body for 

Record Type: Company-Shareholders”. 

While all rows will be 1100 characters long, each section will have a specific number of 

characters (for example 23 in header, 691 in Body for Record Type: Personal Data) that are 

data, and the difference from that number and 1100 that are simply spaces that make up a 

“Filler”. 

In any row, the first character will always be the “Record Type”. This allows the System to know 

what format to expect in the specific row. In our examples above, the row that contained data on 

21 of 92

an Individual would start with “P” for personal, while the row containing data on Company- 

Shareholder Links would start with “L”. 

Please note that the order in which the different rows appear does not matter, as long as they all 

correctly begin with the appropriate Record Type, and as long as the first row is the header and 

the last row is the footer. 

5.1.1 SUBJECT DATA FILE RULES 

The following table details the correct procedure to validate the Subject Data File. Some cells 

refer to Tables that are provided in the following sections 

The Column “FROM” provides the position in the row where the first character of the specific field 

that is being passed begins on. 

The Column “TO” provides the position in the row where the last character of the specific field 

that is being passed ends on. 

The Column “Description” indicates what specific field is being passed. 

The Column “COMMENTS” provides comments on the field being passed. Most times these 

comments will better define what the field is, or give examples of values it could take. In the 

case of “Dependent” fields (please see below), it indicates the dependency. 

The Column “TYPE” indicates whether the field is Numeric (N) or Alphanumeric (X). Please refer 

to section 4.3.4 and 4.3.5 for more information. 

The Column “MANDATORY/NON MANDATORY/DEPENDENT” indicates whether the field must be 

provided every time or not necessarily. Any fields marked as Mandatory (M) for a specific row 

must be provided or that row will result in an error and will not be loaded to the System. Any 

fields marked as Non-Mandatory (NM) for a specific row can be provided or not, at the discretion 

of the contributing FI. While not providing NM fields will not result in an error, WE STRONGLY 

SUGGEST that if the information is available it should be provided. The more information 

provided to the System, the more effective the System becomes, and the highest the value of 

the System becomes for Banks. Any fields marked as Dependent (D) could be either mandatory 

or not depending on the value of other fields. A specific indication is provided for each of these 

fields to indicate when the fields are mandatory and when not. 

The Column “LENGTH” provides the total number of characters that make up the field. It is 

directly related to the “FROM” and “TO” columns. 

The Column “RULES” provides specific information on any rules that exist to fill the specific field, 

such as formatting rules (for example if a field must be entered DDMMYYYY), or indication of 

specific values (for example "H" for the header). 

22 of 92

FROM TO FIELD NAME COMMENTS TYPE Mandatory/Non 

Mandatory/ 

Dependent 

LENGTH RULES 

Header 

1 1 Record Type X M 1 "H" for the header 

2 4 F.I. Code Financial Institute Code (official 

code that identifies the specific 

FI) 

5 12 Accounting Date Date of the last day of the 

month for accounting 

computing 

X M 3 Fill with '0' in case of codes with less 

than 3 characters (i.e. 002, 020, 

240) 

N M 8 format DDMMYYYY 

13 20 Production Date Date of Production of the file N M 8 format DDMMYYYY 

21 23 Code to link Contract 

Data File 

It is a progressive number 

assigned by F.I. 

Data Length 23 

24 1100 FILLER 1077 

Total Record Length Header 1100 

X M 3 It must correspond to the field Code 

to Link Subject Data File in Contract 

Data File 

Body for Record Type: Personal Data 

1 1 Record Type X M 1 "P" for Personal Data 



FI) 

5 8 Branch Code Code of the branch of the 

Financial Institute to which 

record data belong 

9 24 F.I. Subject Code It is the unique Code for the 

individual assigned by the 

Financial Institute (each single 

subject must have a specific 

code) 



240) 

X NM 4 

X M 16 

23 of 92

25 44 Title (i.e. Md, Hajee, Lt. Colonel, 

Major, Major General, Munshi, 

Gazi) 

45 114 Name Full name (avoid use of 

abbreviation). If the value is 

too long it must be cut 

115 134 Father's Title (i.e. Md, Hajee, Lt. Colonel, 


Gazi) 

135 204 Father's Name Full name (avoid use of 



205 224 Mother's Title (i.e. Md, Hajee, Lt. Colonel, 


Gazi) 

225 294 Mother's Name Full name (avoid use of 



295 314 Husband's Title (i.e. Md, Hajee, Lt. Colonel, 


Gazi) 

315 384 Husband's Name Full name (avoid use of 

abbreviation); in case of 

married women. If the value is 


385 385 Sector Type the field is mandatory if Sector 

code is present 

386 391 Sector Code the field is mandatory if sector 

type is present 

24 of 92 

X NM 20 

X M 70 

X NM 20 

X M 70 

X NM 20 

X M 70 

X NM 20 

X NM 70 

N D 1 see Table Sector Type 

N D 6 see Table Sector Code 

392 392 Gender X NM 1 see Table Gender 

393 400 Date of Birth N NM 8 format DDMMYYYY 

401 420 Place of Birth (District) when the field is not available, 

fill with 'UNKNOWN' 

X M 20 

421 422 Country of Birth (Code) X NM 2 see Table Country Codes 

423 435 National ID Number N D 13 

436 436 National ID Number if National ID number is not N M 1 accepted values are: 0,1. If 'National

avaliable/not available 

available, National ID number 

field is NM 

ID Number avaliable/not available' = 

1 then 'National ID Number' must be 

present; 'National ID Number 

avaliable/not available' = 0 when 

'National ID Number' is not present 

437 448 T.I.N. Taxpayer Identification Number X NM 12 only input accepted are N(3)-N(3)- 

N(4) or N(3)/N(3)/N(4) or only 

numeric N(10), that is either a 

numeric of ten or 3 digits followed by 

3 digits followed by 4 digits and 

separated either by "-" or "/" 

449 518 Address:street + nr. Referred to permanent 

address. If the value is too long 

it must be cut 

X M 70 

519 522 Address:Postal CODE Referred to permanent address N NM 4 

523 542 Address: District Referred to permanent address X M 20 

543 544 Address:Country(Code) Referred to permanent address X NM 2 see Table Country Codes 

545 614 Additional Address:street 

+ nr. 

615 618 Additional Address:Postal 

CODE 

619 638 Additional Address: 

District 

639 640 Additional 

Address:Country(Code) 

Referred to current address. If 

the value is too long it must be 

cut; the field is mandatory if 

other additional address fields 

are present 

Referred to current address (if 

different from permanent); the 

field is mandatory if other 

additional address fields are 

present 





present 





present 

X D 70 

N D 4 

X D 20 

X D 2 see Table Country Codes 

25 of 92

641 641 ID Type The field is mandatory if other 

ID fields are present. 

642 661 ID Nr. The field is mandatory if other 


662 669 ID Issue Date The field is mandatory if other 


670 671 ID Issue Country (Code) The field is mandatory if other 


672 691 Phone Nr. in case of Bangladesh Phone do 

not include the international 

prefix 

X D 1 see Table ID 

X D 20 

N D 8 format DDMMYYYY 


X NM 20 


692 1100 FILLER 409 

Total Record Length 1100 

Body for Record Type: Individual Concern 

1 1 Record Type X M 1 "I" for Individual Concern 



FI) 





individual concern assigned by 

the Financial Institute (each 

single subject must have a 

specific code) 

26 of 92 



240) 

X NM 4 

X M 16 

25 44 Title (i.e. M/S) X NM 20 

45 164 Trade name This field does not have to 

contain notes or comments, 

only the name of the Company 

(without the legal form). If the 

value is too long it must be cut 

X M 120 

165 165 Legal Form N M 1 see Table Legal Forms; only 

Proprietorship admitted








N(4) or N(3)/N(3)/N(4) or only 





185 254 Address:street + nr. Referred to Proprietorship 

permanent address. If the 


255 258 Address:Postal CODE Referred to Proprietorship 

permanent address 

259 278 Address: District Referred to Proprietorship 


279 280 Address:Country(Code) Referred to Proprietorship 



+ nr. 


CODE 


District 



Referred to Proprietorship 

business address. If the value 

is too long it must be cut; the 


address fields are present 


business address. The field is 

mandatory if other address 

fields are present 









X M 70 

N NM 4 

X M 20 

X NM 2 see Table Country Codes, 

X D 70 

N D 4 

X D 20 

X D 2 see Table Country Codes, 

27 of 92

377 396 Phone Nr. Referred to Proprietorship. in 

case of Bangladesh Phone do 


prefix 

397 416 Owner's Title (i.e. Md, Hajee, Lt. Colonel, 


Gazi) 

417 486 Owner's Name Full name (avoid use of 



487 506 Owner's Father's Title (i.e. Md, Hajee, Lt. Colonel, 


Gazi) 

507 576 Owner's Father's Name Full name (avoid use of 



577 596 Owner's Mother's Title (i.e. Md, Hajee, Lt. Colonel, 


Gazi) 

597 666 Owner's Mother's Name Full name (avoid use of 



667 686 Owner's Husband's Title (i.e. Md, Hajee, Lt. Colonel, 


Gazi) 

687 756 Owner's Husband's Name Full name (avoid use of 

abbreviation); in case of 

married women. If the value is 


28 of 92 

X NM 20 

X NM 20 

X M 70 

X NM 20 

X M 70 

X NM 20 

X M 70 

X NM 20 

X NM 70 

757 757 Owner's Gender X NM 1 see Table Gender 

758 765 Owner's Date of Birth N NM 8 format DDMMYYYY; 

766 785 Owner's Place of Birth 

(District) 

786 787 Owner's Country of Birth 

(Code) 

788 800 Owner's National ID 

Number 

when the field is not available, 

fill with 'UNKNOWN' 

X M 20 

X NM 2 see Table Country Codes 

N D 13

801 801 National ID Number 

avaliable/not available 

if National ID number is not 

available, National ID number 

field is NM 

802 813 Owner's T.I.N. X NM 12 

814 883 Owner's Address:street + 

nr. 

884 887 Owner's Address:Postal 

CODE 

Referred to permanent 


it must be cut 

N M 1 accepted values are: 0,1. If 'National 

ID Number avaliable/not available' = 

1 then 'National ID Number' must be 

present; 'National ID Number 

avaliable/not available' = 0 when 

'National ID Number' is not present 

X M 70 

Referred to permanent address N NM 4 

888 907 Owner's Address: District Referred to permanent address X M 20 

908 909 Owner's 


910 979 Owner's Additional 

Address:street + nr. 


Address: Postal CODE 


Address: District 



Referred to permanent address X NM 2 see Table Country Codes 

Referred to current address if 

different from permanent. If 

the value is too long it must be 

cut; the field is mandatory if 

other address fields are present 


different from permanent; the 



present 





present 





present 

1006 1006 Owner's ID Type the field is mandatory if other 

ID fields are present 

X D 70 

N D 4 

X D 20 


X D 1 see Table ID 

29 of 92

1007 1026 Owner's ID Nr. the field is mandatory if other 


1027 1034 Owner's ID Issue Date the field is mandatory if other 


1035 1036 Owner's ID Issue Country 

(Code) 

in case of Bangladesh Phone do 


prefix 

X D 20 




1037 1100 FILLER 64 


Body for Record Type: Companies 

1 1 Record Type X M 1 "C" for Companies 



FI) 





company assigned by the 



code) 



240) 

X NM 4 

X M 16 

25 44 Title (i.e. M/S) X NM 20 

45 164 Trade name This field does not have to 

contain notes or comments, 

only the name of the Company 

(without the legal form). If the 






X M 120 



172 172 Legal Form N M 1 see Table Legal Forms 

30 of 92


N(4) or N(3)/N(3)/N(4) or only 





185 254 Address:street + nr. Referred to Company 

permanent address. If the 


255 258 Address: Postal CODE Referred to Company 


259 278 Address: District Referred to Company 


279 280 Address:Country(Code) Referred to Company 



+ nr. 


CODE 


District 



Referred to company business 


it must be cut; the field is 

mandatory if other additional 

address fields are present 

Referred to Company business 

address. The field is mandatory 

if other additional address 










X M 70 

N NM 4 

X M 20 

X NM 2 see Table Country Codes, 

X D 70 

N D 4 

X D 20 

377 396 Phone Nr. X NM 20 

X D 2 see Table Country Codes, 


397 1100 FILLER 704 


31 of 92

Body for Record Type: Company-Shareholders 

1 1 Record Type X M 1 "L" for Company-Shareholder link 



FI) 


Financial Institute the file 

comes from 

9 24 F.I. Subject Code of 

Company 

It is the unique Code for the 

company assigned by the 



code) 

25 25 Role Role that the 

Shareholder/Owner has in the 

Company 

26 41 F.I. Subject Code of 

Shareholder 

It is the unique Code for the 

sharholder/owner assigned by 

the Financial Institute (each 

single subject must have a 

specific code) 



240) 

X NM 4 


42 1100 FILLER 1059 


X M 16 The Company subject info must have 

been submitted by the FI within the 

same or previous contributions 

X M 1 see Table Shareholders Types Type 

X M 16 The Individual subject info must 

have been submitted by the FI 

within the same or previous 

contributions 

Footer 

1 1 Record Type X M 1 "Q" for the Queue 

2 4 F.I. Code Financial Institute Code X M 3 Fill with '0' in case of codes with less 


240) 

5 12 Accounting Date Date of the last day of the 

month for accounting 

computing 

32 of 92 

N M 8 format DDMMYYYY 


21 27 Nr. of records Total number of records in the 

file (note this excludes header 

N M 7

and footer rows) 


28 1100 FILLER 1073 


33 of 92

5.2 CONTRACT DATA FILE 

The Contract Data File is a continuous, space delimited .txt file that has between 2 and 

9.999.999 rows of information. 

The first row (and only the first row) will ALWAYS be the Header. Please refer to Annex 5.2 for 

the rules to fill the header row. Note that this Header will be identical to the one of the related 

Subject Data File, except for the length of the filler, and therefore the total length. 

The last row (and only the last row) will ALWAYS be the Footer. Please refer to Annex 5.2 for the 

rules to fill the footer row. Note that this Header will be identical to the one of the related Subject 

Data File, except for the length of the filler, and therefore the total length. 

In between the header and the footer, there will be a varying number of lines, each carrying 

different sets of information. 

ALL rows (including the Header and the Footer) will ALWAYS be 600 characters long, but the 

composition of each row depends on the type of information that is being provided in that 

particular line. 

Specifically, the type of information that the Contract Data file 

provides are the following: 

• 1 row of 600 characters which is the header 

• 1 row of 600 characters which is the footer 

• In between, it contains: 

• 0 to “n” rows of 600 chars each of Financial Information 

divided into 250 chars of general contractual info (see “Body 

for Record Type: General information for all types of 

Financing”) and 350 chars specific to whether the contract is 

instalment, non instalment, or credit card (see “Body for 

Record Type: Instalment contracts”, “Body for Record Type: 

Cards contracts”, and Body for Record Type: Non Instalment 

contracts” respectively) 

• 0 to “n” rows of 600 chars each that provide the Risk Grading, 

Y score and Z score of any subject (see Body for Record Type: 

Subject Information) 

• 0 to “n” rows of 600 chars each that provide the link between 

each contract and each Subject on the contract, indicating the “role” such subject has on 

the contract - co-borrower, guarantor. (see "Body for Record Type: contract Links”) 

• Number of rows is up to 9.999.999 

Depending on which of the above information a particular row contains, different rules must be 

used to fill out such row. Therefore if a particular row contains Financial information about an 

Overdraft Contract, for example, we will need to follow the instructions for “Body for Record 

Type: General information for all types of Financing” of section 5.2 for the first 250 characters 

of the row, followed by instructions for “Body for Record Type: Non Instalment contracts” of 

section 5.2 for the remaining 450 characters of the row (since we can see from table 5.4.21 that 

Overdraft is a type of Non-Installment contract). Conversely if the information in the row is a 

Contract link indicating the Co-Borrower of a specific contract, for example, the row must be 

filled out according to the rules in “Body for Record Type: contract links”. 

While all rows will be 600 characters long, each section will have a specific number of characters 

(for example 23 in header, 58 in Body for Record Type: contract li) that are data, and the 

difference from that number and 600 that are simply spaces that make up a “Filler”. 

In any row, the first character will always be the “Record Type”. This allows the System to know 

what format to expect in the specific row. In our examples above, the row that contained data on 

an Overdraft would start with “D” for contract detail, while the row containing data on Contract 

Links would start with “G”. 

34 of 92

Please note that the order in which the different rows appear does not matter, as long as they all 

correctly begin with the appropriate Record Type, and as long as the first row is the header and 

the last row is the footer. 

5.2.1 SPECIAL NOTES FOR THE REPORTING OF INSTALMENT CONTRACTS 

Instalment Contracts are Contracts where the financed amount is disbursed at once, but paid 

back through periodical partial payments, i.e. Instalments. Therefore, when looking at Instalment 

Contracts, we track the original financed amount (Total Financed Amount), the number of partial 

payments that will be paid during the life of the Contract as well as the value of each payment if 

these payments were to be done on a monthly basis for the life of the contract (to get an 

average value that can be compared across all Instalment loans), the number of Overdue and 

not Paid Instalments as well as the total Value of such Overdue and not Paid Instalments, and 

the number of Remaining Instalments (i.e. not yet paid, but also not overdue yet) as well as the 

total value of the amount that remains to be paid but is not Overdue yet. Naturally there must be 

consistency between these numbers. Therefore if we have a number equal to 0 (whether it‟s 

Total Number of Instalments, or of overdue instalments, or of remaining instalments), then the 

associated value must also be 0 (so for example we cannot have Number of Overdue 

Instalments=0, but value of Overdue Instlaments >0). At the same time, the total number of 

instalments must be equal to paid instalments, plus overdue and not paid instalments, plus 

remaining instalments. Therefore it follows that overdue and not paid instalments plus remaining 

instalment can never be more than total instalments. 

5.2.2 SPECIAL NOTES FOR THE REPORTING OF CREDIT CARD TYPE 

CONTRACTS 

Revolving credit lines and credit lines financed through the use of credit cards are those for which 

a credit limit is made available, to be used partially or in its entirety and also at different times, 

for the purchase of goods and services from participating retailers or for the attainment of funds 

availability. When the card is used during the reference period, the FI charges the customer the 

due amount (as a deferred payment) based on of the characteristics of the card. 

The FI must send information to CIB regarding every card credit report open on a data client‟s 

account that meets the contribution requirements which has the same debit and the same 

account statement. Therefore, if there are additional cards within the same card credit report or 

if the cards are used by other data clients which are different from the account signatory and 

everything is billed at the same time, the contribution to CIB is carried out only once in the name 

of the account signatory who is the client that assumes the risk for the purposes of CIB. 

As for all other credit lines client to contribution to CB, the reporting of credit card-type credit 

lines must also be carried out by the 5 th working day of the month subsequent to the reference 

month. When a card is used by the data client and is charged in the month of the monthly 

contribution to CIB, if the information regarding payment of this charge has not yet been 

received by the FI by the 5 th working day of the month, the contribution of the charge and the 

use of the card by the data client must be sent in the next month. 

5.2.3 SPECIAL NOTES FOR THE REPORTING OF NON INSTALMENT 

CONTRACTS 

Non Instalment Contracts are Contracts where a maximum financed amount (Credit Limit) is 

made available to the Subject, but not necessarily disbursed to the Subject. The Subject is then 

allowed to “draw down” from this amount up to the limit. The amount that at any one point is 

drawn down (including any accrued interest on it) is the Utilization of the credit. This is likely to 

vary repeatedly as any draw down from and payment to the credit will shift the Utilization 

accordingly. Therefore the amounts to be reported are the ones at the end of the reference 

month. 

35 of 92

5.2.4 SPECIAL NOTES FOR THE REPORTING OF LINKS 

Since you are providing a separate file for Subjects (see 5.1), and a separate file for Contracts, 

there needs to be a way to link each specific contract to one (or more) specific Subjects. 

In particular, each contract must be linked to one, and only one, specific Borrower. 

Additionally, each contract can be linked to one, or more, specific Co-Borrowers and/or one, or 

more, specific Guarantors. This means that the relationship between Contract and Borrower is 

one-to-one, while the relationship between Contract and Co-Borrower as well as between 

Contract and Guarantor is one-to-many. As these relationships are different, not surprisingly the 

way to contribute the relationship to the system is also different. 

5.2.4 Contract-Borrower link 

In order to link a specific Contract to a Specific Borrower, you will simply have to pass the F.I. 

Subject Code in the same line as the contract. 

In other words, when passing the contract information (and remember, each specific contract will 

be passed as one line in the batch contribution), in section “Body for Record Type: General 

information for all types of Financing” you will enter the F.I. Subject Code in positions 9 to 24 

(please see 5.2.5). Again, each contract MUST have one and only one Subject associated with it. 

The Subject must either be contributed as part of the Subject file in the same batch submission, 

or must have been submitted in the past by the Institution in a separate batch submission 

(otherwise the contract will go in error and be stored in the anomalies tables). 

As the contract information is sent each month, and the F.I. Subject Code of the Borrower is a 

mandatory field of the Contract contribution, this information is sent each month during the 

lifecycle of the contract. 

5.2.4 Contract-Co Borrower and Contract-Guarantor link(s) 

Instead, if you want to contribute any number of Co Borrowers, and/or a Guarantors on the 

contract, this information needs to be passed as a separate line in the batch submission for each 

Subject being linked. 

Therefore, for each Co Borrower and/or Guarantor on a contract, you will enter a separate row in 

the contract file, following the rules set out in “Body for Record Type: contract Links” section 

under 5.2.5 below. This line will include the F.I. Contract Code to identify the specific contract we 

are talking about (and such contract must be contributed within the same contract file or must 

have been contributed by the Institution in the past), the F.I. code of the specific Co Borrower or 

Guarantor that we are trying to link (called here F.I. Secondary Code), as well as the F.I. code 

of the main Borrower (called here F.I. Primary Secondary Code) which must match what was 

contributed in the specific contract row as indicated in 5.2.3. 

It is enough to send the Co Borrowers and Guarantors on a specific Contract once, it is not 

necessary to send the same link each month. At the same time, if you provide the same link 

each month for the same Contract this will not cause errors. If instead you send a new Co 

Borrower or a New Guarantor link on an existing Contract, the System will add the link. On the 

other hand, if you need to remove a Co Borrower or a Guarantor you cannot do so directly, but 

must contact CIB (please see 6.1) 

5.2.5 CONTRACT DATA FILE RULES 

The following table details the correct procedure to validate the Contract Data File. Some cells 

refer to Tables that are provided in the following sections 

The Column “FROM” provides the position in the row where the first character of the specific field 

that is being passed begins on. 

36 of 92

The Column “TO” provides the position in the row where the last character of the specific field 

that is being passed ends on. 

The Column “Description” indicates what specific field is being passed. 

The Column “COMMENTS” provides comments on the field being passed. Most times these 

comments will better define what the field is, or give examples of values it could take. In the 

case of “Dependent” fields (please see below), it indicates the dependency. 

The Column “TYPE” indicates whether the field is Numeric (N) or Alphanumeric (X). Please refer 

to section 4.3.4 and 4.3.5 for more information. 

The Column “MANDATORY/NON MANDATORY/DEPENDENT” indicates whether the field must be 

provided every time or not necessarily. Any fields marked as Mandatory (M) for a specific row 

must be provided or that row will result in an error and will not be loaded to the System. Any 

fields marked as Non-Mandatory (NM) for a specific row can be provided or not, at the discretion 

of the contributing FI. While not providing NM fields will not result in an error, WE STRONGLY 

SUGGEST that if the information is available it should be provided. The more information 

provided to the System, the more effective the System becomes, and the highest the value of 

the System becomes for Banks. Any fields marked as Dependent (D) could be either mandatory 

or not depending on the value of other fields. A specific indication is provided for each of these 

fields to indicate when the fields are mandatory and when not. 

The Column “LENGTH” provides the total number of characters that make up the field. It is 

directly related to the “FROM” and “TO” columns. 

The Column “RULES” provides specific information on any rules that exist to fill the specific field, 

such as formatting rules (for example if a field must be entered DDMMYYYY), or indication of 

specific values (for example "H" for the header). 

37 of 92

FROM TO FIELD NAME COMMENTS TYPE Mandatory/ 

Non 

Mandatory/ 

Dependent 

LENGTH 

RULES 

Header 

1 1 Record Type X M 1 "H" for Header 

2 4 F.I. Code Financial Institute Code (official code that identifies the X M 3 Fill with '0' in case of codes with less than 3 

specific FI) 

characters (i.e. 002, 020, 240) 

5 12 Accounting Date Date of the last day of the month for accounting computing N M 8 format DDMMYYYY 


21 23 Code to link Subject Data File It is a progressive number assigned by F.I. X M 3 It must correspond to the field Code to Link Contract 

Data File in Subject Data File 


24 600 FILLER 577 


Body for Record Type: General information for all types of Financing 

1 1 Record Type X M 1 "D" for contract Detail 

2 4 F.I. Code Financial Institute Code X M 3 Fill with '0' in case of codes with less than 3 

characters (i.e. 002, 020, 240) 

5 8 Branch Code Code of the branch of the Financial Institute to which record X NM 4 

data belong 

9 24 F.I. Subject Code Code of the Individual/Prprietorship/Company assigned by 

Financial Institute for the Borrower 

X M 16 Must be the Subject Code of the Main Borrower on 

the contract being contributed 

25 40 F.I.Contract Code Code of the contract assigned by Financial Institute X M 16 

41 42 contract Type X M 2 see Table contract Types 

43 44 contract Phase Requested, Refused/Renounced, Living, 

X M 2 see Table contract Phases 

Terminated/Terminated in advance 

45 45 contract Status Information about the contract X M 1 see Table contract Status 

46 48 Currency Code (in file) The code of the currency used for indicating amount values in X M 3 must be = BDT 

batch file 

49 51 Currency Code of Credit The code of the currency in which the credit was granted X M 3 see Table Currency Codes 

52 59 Starting date of the contract The field is Mandatory if contract Phase=Living, 

Terminated/Terminated in advance 

60 67 Request date of the contract The date in which the credit was first requested. If unknown, 

fill the field with staring date of the contract 

68 75 Planned End Date of the contract The field is Mandatory only if contract Phase=Living, 

Terminated/Terminated in advance and Instalment contract 

76 83 Actual End Date of the contract The field is Mandatory only if contract 

Phase=Terminated/Terminated in advance 

38 of 92 




N D 8 format DDMMYYYY

84 91 Date of Last Payment The date refers to the last payment from customer to FI; it N NM 8 format DDMMYYYY 

should be filled if the customer has paid at least once 

92 92 Flag Subsidized Credit in case the credit has some subsidies from public bodies X NM 1 see Table Subsidized Credit 

93 93 Flag pre-finance of Loan In case the current loan is simply a pre-finance of another loan X NM 1 see Table Pre-Finance of Loan 

that will be issued in the future 

94 94 Code Reorganized Credit When conditions of the credit are re-discussed: new rates, X NM 1 see Table Re-organized Credit 

new planning, etc. are decided 

95 97 Personal Guarantee Type X NM 3 see Table Personal Guarantee Type 

98 100 Real Guarantee Type X NM 3 see Table Real Guarantee Type 

101 112 Amount guaranteed by Personal Guarantee N NM 12 Must be filled with zeroes in case the amount is not 

available 

113 124 Amount guaranteed by Real Guarantee N NM 12 Must be filled with zeroes in case the amount is not 

available 

Data Length of contract General Information 124 

125 250 FILLER 126 

Total Length of contract General Information 250 

Body for Record Type: Instalment contracts 

251 262 Total financed amount Total amount of financing N M 12 

263 265 Total Number of Instalments N M 3 

266 266 Periodicity of Payment X M 1 see Table Frequency of Payment 

267 269 Method of Payment X NM 3 see Table Method of Payment 

270 281 Monthly Instalment Amount in case of instalments with constant amount and constant 

frequency of payment: Instalment Amount/Nr. of months of 

Payment Frequency; in case of instalments with variable 

amount and/or variable frequency of payment: Total 

Amount/Total nr. of months of reimbursement 

282 289 Expiration Date of Next Instalment it refers to expiration date of next instalment; normally it is 

empty when contract Phase is different from Living 

290 301 Amount of Next Expiring 

Instalment 

N D 12 The field is Mandatory if contract Phase=Living, 

Terminated/Terminated in Advance 

Please note, this is simply needed for Online CIB 

purtposes, it does not reflect a policy change in 

ledger keeping of banks 

N NM 8 format DDMMYYYY 

Please Note: this field actually refers to the amount of the N NM 12 

NEXT expiring Installment, i.e. the upcoming instalment; 

normally it is empty when contract Phase is different from 

Living 

302 304 Number of remaining Instalments The field is mandatory if contract Phase=Living N D 3 The number of instalments with a due date after the 

date of the last update, or those for which the 

transaction processing time necessary for 

registration of the payment has not yet elapsed. It 

should always refer to the total number of 

installments for the credit line, independently of the 

frequency of payment outlined in the credit line 

contract. This means that even if the frequency is 

not monthly, the actual number of installments 

detailed in the amortization plan is confirmed. 

39 of 92

305 316 Remaining Amount The field is Mandatory if contract Phase=Living; it must be 

zero when phase is Terminated,Terminated in advance 

317 319 Number of Overdue and not Paid 

Instalments 

The field is Mandatory in case there are Overdue and not paid 

Amount; it must be filled with zeroes if contract 

Phase=Requested, Renounced/Refused 

320 331 Overdue and not Paid Amount It is the amount corresponding to the Nr. of Overdue and not 

Paid Instalments; it must be filled with zeroes if contract 

Phase=Requested, Renounced/Refused 

332 334 Number of days of payment delay From 0 to 29 days of delay, the payment is defined as regular, 

and it must be passes as 000 days of payment delay, from 30 

to 59 it will be 030, from 60 to 89 it will be 060, and so on. 

From 180 to anything more it will be 180 

N D 12 Please note that the Remaining Amount does not 

include Overdue and Not Paid Amount. In other 

words, each month the Total Remaining Amount is 

going to decrease simply because another month is 

passed, whether an instalment was paid or not in 

that month. 

N D 3 The number of instalments for which it is certain that 

the customer has missed payment according to the 

criteria adopted by the User. It should always refer 

to the total number of installments for the credit line, 

independently of the frequency of payment outlined 

in the credit line contract. This means that even if 

the frequency is not monthly, the actual number of 

installments detailed in the amortization plan is 

confirmed. 

N D 12 

N NM 3 accepted values are: "000" ; "030" ; "060" ; "090" ; 

"120" ; "180" 

335 335 Type of leased good X NM 1 See table "Types of leased good" 

336 347 Value of leased good N NM 12 

348 348 New/used Is the leased good new or used X NM 1 See table "Types of leased good - FlagNewUsed" 

349 388 Brand Brand of the leased good if it is a vehicle X NM 40 

389 428 Registration number Identifying code of good if it is a vehicle X NM 40 

429 436 Date of manufacturing N NM 8 format DDMMYYYY 

437 448 Due for recovery Total amount that could have been recovered during the N NM 12 

period. FI should calculate it as Overdue and not Paid Amount 

+ Recovery during the reporting period 

449 460 Recovery during the reporting How much was recovered during the period thanks to recovery N NM 12 

period 

efforts by FI 

461 472 Cumulative recovery How much was recovered since the beginning of the contract N NM 12 

thanks to recovery efforts by FI 

473 480 Date of law suit N NM 8 format DDMMYYYY 

481 488 Date of classification Date in which the current classification was set (i.e. date in 

which subject changed from previous to current classification) 

489 490 No. of time(s) rescheduled N NM 2 


491 494 Economic purpose code X NM 4 see Table Economic purpose 

Data Length of Instalment contracts 244 

495 600 FILLER 106 

Total Length of Instalment contracts 350 

40 of 92

Body for Record Type: Cards contracts 

251 251 Periodicity of Payment The field is Mandatory for contract type = CR, CG and in these X D 1 see Table Frequency of Payment 

cases it means periodicity of the charge 

252 254 Method of Payment X NM 3 see Table Method of Payment 

255 266 Monthly Instalment Amount in case of instalments with constant amount and constant N D 12 

frequency of payment: Instalment Amount/Nr. of months of 

Payment Frequency; in case of instalments with variable 

amount and/or variable frequency of payment: Total 

Amount/Total nr. of months of reimbursement. The field must 

be filled with zeroes if contract Type=CG; NM if contract 

Phase=Living, Terminated/Terminated in Advance and 

contract Type=CR, RV: M if contract Type=CR and Type of 

instalment=Fixed 

267 278 Credit limit N M 12 Set 999999999999 when the card is unlimited 

279 286 Expiration Date of Next Instalment It must be filled with zeroes if contractType=CG; Not 

Mandatory if contract Phase=Living and contract Type=CR, RV 

287 298 Remaining Amount it must be filled with zeroes if contract 

Phase=Requested,Renounced/Refused or if there is not 

Residual Amount; NM if contract type= RV 

299 301 Number of Overdue and not Paid The field is mandatory in case there is Overdue and not paid 

Instalments 

Amount >0; it must befilled with zeroes if contract 

Phase=Requested,Renounced/Refused or contract type=CG; 

NM if contract type= RV 

302 313 Overdue not Paid Amount The field is Mandatory in case there are Number of Overdue 

and not paid Instalments >0 (also in case of contract CG); it 

must be filled with zeroes if contract Phase=Requested, 

Renounced/Refused; NM if contract type= RV 

41 of 92 


N D 12 

N D 3 The number of instalments for which it is certain that 

the customer has missed payment according to the 

criteria adopted by the User. It should always refer 

to the total number of installments for the credit line, 

independently of the frequency of payment outlined 

in the credit line contract. This means that even if 

the frequency is not monthly, the actual number of 

installments detailed in the amortization plan is 

confirmed. 

N D 12 

314 321 Date of Last Charge N NM 8 format DDMMYYYY 

322 322 Type of Instalment Fixed or variable; set always variable for contract Type = CR, X M 1 see Table Type of instalment 

not used for other type of contract 

323 334 Amount charged in the month Not Mandatory for contract Type=CG,CR; not used in case of N NM 12 

RV or contract Phase=Requested,Refused/Renounced 

335 335 Flag Card used in the month X NM 1 see Table Card used in the month 

336 337 How many times Card has been Only for contract type=CG,CR N NM 2 

used in the month 

338 340 Number of day of payment delay From 0 to 29 days of delay, the payment is defined as regular, 



"120" ; "180" 



341 352 Due for recovery Total amount that could have been recovered during the 



N NM 12

353 364 Recovery during the reporting How much was recovered during the period thanks to recovery N NM 12 

period 


365 376 Cumulative recovery How much was recovered since the beginning of the contract N NM 12 








Data Length of Credit Cards contracts 148 

399 600 FILLER 202 

Total Length of Credit Cards contracts 350 

Body for Record Type: Non Instalment contracts 

251 262 Credit Limit The total limit of the credit N M 12 

263 274 Utilization How much of the credit was actually used in the month N M 12 

275 277 Nr. of days of payment delay From 0 to 29 days of delay, the payment is defined as regular, 




278 289 Due for recovery Total amount that could have been recovered during the 



290 301 Recovery during the reporting How much was recovered during the period thanks to recovery 

period 


302 313 Cumulative recovery How much was recovered since the beginning of the contract 



"120" ; "180" 

N NM 12 

N NM 12 

N NM 12 







Data Length of non Instalment contracts 85 

336 600 FILLER 265 

Total Length of non Instalment contracts 350 

Body for Record Type: Subject Information 

1 1 Record Type X M 1 "S" for Subject Information 


specific FI) 

characters (i.e. 002, 020, 240) 


42 of 92

data belong 

9 24 F.I. Subject Code Code of the Subject (Individual, Sole Trader, Company) X M 16 

assigned by Financial Institute 

25 26 Risk Grading X NM 2 

27 28 Y score N NM 2 

29 33 Z score Decimal separator to be used is '.' (i.e. 10.00, 22.45, 10.03) decimal NM 5 

(4,2) 


34 600 FILLER 567 


Body for Record Type: contract Links 

1 1 Record Type X M 1 "G" 

2 4 F.I. Code Financial Institute Code (official code that identifies the 

specific FI) 

X M 3 Fill with '0' in case of codes with less than 3 

characters (i.e. 002, 020, 240) 


data belong 

9 9 Type of Link Type of link to the contract X M 1 G in case of link between Guarantor; C in case of link 

between Co-borrowers. See table Link Type 

10 25 F.I. Primary Code Code of the first Subject Code of the link (the Code of the X M 16 

borrower of the credit) 

26 41 F.I. Secondary Code Code of the other Subject Code of the link X M 16 if Type of Link = G, it is the code of the Guarantor; if 

Type of Link = C, it is the code of the Co-borrower 

42 57 FI contract code Code of the contract assigned by Financial Institute X M 16 


58 600 FILLER 543 


Footer 

1 1 Record Type X M 1 "Q" for Queue 


specific FI) 

characters (i.e. 002, 020, 240) 

5 12 Accounting Date Date of the last day of the month for accounting computing N M 8 format DDMMYYYY 


21 27 Nr. of records Total number of records in the file (note this excludes header N M 7 

and footer rows) 


28 600 FILLER 573 


43 of 92

5.3 ERRORS FILE 

In each file, the first row shows the name of each column. Please find the specific structure of the 

different error files. 

Structure of ACA and CTA error file 

FROM TO FIELD NAME COMMENTS TYPE LENGTH 

1 7 FI Code FI code X 7 

8 21 Reference Date It is the Accounting date of input file X 14 

22 37 FI Subject Code Indicates the subject code of the 

subject with the error. 

X 16 

38 47 Error Type See table errors X 10 

48 57 Error Code See table errors X 10 

58 117 Wrong Value Where it is possible, the value of the 

field that raised the error is reported 

X 60 

Structure of ACC and CTC error file 




22 56 FI Contract Code Indicates the contract code of the contract 

with the error. 

57 72 FI Subject Code Indicates the applicant subject code of the 

contract with the error. 

X 35 

X 16 



93 152 Wrong Value Where it is possible, the value of the field 

that raised the error is reported 

X 60 

Structure of ACL and CTL error file 




22 37 FI Secondary 

Code 

It is the FI Subject Code of Shareholder 

when the record type = „L‟; it is the FI 

Secondary Code of record when the record 

type = „G‟. It is empty for other link type. 

38 53 FI Subject Code It is the FI Primary Code of record when 

the record type = „G‟; it is the FI Subject 

Code when the record type = „S‟; it is the 

FI Subject Code of Company when the 

record type = „L‟ 

54 88 FI Contract Code It is the FI Contract Code of record when 

the record type = „G‟. It is empty for other 

link type. 

89 97 Link Type Link type = 1 for records with record type 

= „G‟ in contract file; Link Type = 2 for 

records with record type = „S‟ in contract 

file; Link Type =3 for records with record 

type = „L‟ in subject file 

X 16 

X 16 

X 35 

X 9 


44 of 92


118 177 Wrong Value Where it is possible, the value of the field 

that raised the error is reported 

X 60 

File of errors summary after every step 






42 63 Total It is the total numebr of records 

affected by the error 

X 22 

64 363 Error Description Error description X 300 

5.4 BATCH DOMAIN TABLES 

Often the rules in the Subject and Data Files refer to Domain Tables. These are tables that 

indicate the values that a specific field can take. Please find below such tables. 

5.4.1 TABLE GENDER 

Used whenever the gender of a Subject must be communicated. 

Table Gender 

Value 

M 

F 

Description 

Male 

Female 

5.4.2 TABLE LINK TYPES 

Used in the Contract Data table, in the “Body for Record Type: contract Links” section to indicate 

whether the specific Subject being linked to the Specific Contract is a Co-Borrower (C) or a Guarantor 

(G). 

Table Link Types 

Value Description 

C 

Co-Borrower 

G 

Guarantor 

5.4.3 TABLE CONTRACT PHASES 

Used in the Contract Data table, in the “Body for Record Type: General information for all types 

of Financing” section to indicate the specific phase a contract is in. Please remember that there is 

a particular order in which phases can change from one to another. Please see section 4.4 

Table contract Phases 


RQ Requested 

RN Renounced 

RF Refused 

LV Living 

45 of 92

TM 

TA 

Terminated 

Terminated in advance 

5.4.4 TABLE SUBSIDIZED CREDIT 


of Financing” section to indicate whether a particular Contract has received some form of 

government or other agency subsidy or not. 

Table Subsidized Credit 


0 Credit is not subsidized 

1 Credit is subsidized 

5.4.5 TABLE PREFINANCE OF LOAN 


of Financing” section to indicate whether a particular Contract is a pre-finance of another, usually 

larger loan. 

Table Pre-Finance of Loan 


0 Credit is not a pre-finance of loan 

1 Credit is a pre-finance of loan 

5.4.6 TABLE REORGANIZED CREDIT 


of Financing” section to indicate whether a particular Contract is a re-organization of a previous 

credit. Please see section 6.4 for more information on how to contribute reorganized credits. 

Table Re-Organized Credit 


0 Credit is not re-organized 

2 Credit is re-organized by simply updating 

the old contract 

1 Credit is re-organized by closing the old 

contract and creating a new one, while 

keeping a reference link between the two 

5.4.7 TABLE PERIODICITY OF PAYMENT 

Used in the Contract Data table, in the “Body for Record Type: Instalment contracts” and the 

“Body for Record Type: Cards contracts” sections to indicate the periodicity of repayment of a 

particular Contract. 

Table Periodicity of payment 


F fortnight instalments-15 days 

M monthly instalments-30 days 

B bimonthly instalments-60 days 

46 of 92

Q 

T 

C 

S 

Y 

I 

quarterly instalments-90 days 

Trimester four-monthly instalments-120 days 

instalments every five months-150 days 

instalments every six months-180 days 

Yearly instalments-360 days 

irregular instalments 

5.4.8 TABLE TYPE OF INSTALMENT 

Used in the Contract Data table, in the “Body for Record Type: Cards contracts” section to 

indicate whether an instalment card has a fixed or variable term. 

Table Type of instalment 


F fixed 

V variable 

5.4.9 TABLE CARD USED IN THE MONTH 

Used in the Contract Data table, in the “Body for Record Type: Cards contracts” section to 

indicate whether a card has been used in the month or not. 

Table Card used in the month 


0 Card not used in the month 

1 Card used in the month 

5.4.10 TABLE TYPES OF LEASED GOOD 

Used in the Contract Data table, in the “Body for Record Type: Instalment contracts” section to 

indicate what type of leased good the Contract is provided for. If the contract is provided for 

multiple items of different types, either choose the main category (for example if ten cars and 

one truck, select “C”) or omit. 

Types of leased good 


C personal/utilitarian car 

T truck, trailer 

M instrumental - machines and equipment 

R realty 

G consumer goods 

5.4.11 TABLE TYPES OF LEASED GOOD – FLAG NEW/USED 

Used in the Contract Data table, in the “Body for Record Type: Instalment contracts” section to 

indicate whether the leased good the Contract is provided for is new or used. If the Contract is 

provided for multiple items and some are new other are old, either choose the main category (for 

example if ten cars and one truck, select “C”) or omit. 

Types of leased good – FlagNewUsed 


47 of 92

N 

U 

New 

Used 

5.4.12 TABLE METHOD OF PAYMENT 

Used in the Contract Data table, in the “Body for Record Type: Instalment contracts” and the 

“Body for Record Type: Cards Contracts” sections to indicate how the Contract is being repaid. 

Table Method of payment 

Value Description(EN) 

CAD Current Account Debit 

BOE Promissory Note 

BAR Bank draft; Automated bank draft 

DIR Direct transfer; postal payment slip 

ADD Authorization to Direct Current Account Debit 

CCR Credit card payment 

CHQ Cheque 

CAS Cash 

OTH Other 

5.4.13 TABLE PERSONAL GUARANTEE TYPE 


of Financing” section to indicate what type of personal guarantee, if any, is provided under the 

Contract. 

Table Personal Guarantee Type 


110 Payment Guarantee 

072 Guarantee of Individuals / Institutions 

120 Bill of exchange guarantee without guarantee of payment 

130 Unlimited corporate liability 

140 specific corporate liability 

5.4.14 TABLE REAL GUARANTEE TYPE 


of Financing” section to indicate what type of real guarantee, if any, is provided under the 

Contract. 

Table Real Guarantee Type 


100 Automobile hypothecation 

079 Others 

090 Hypothecation over Plant and Machinery 

010 Gold and gold ornaments 

020 Shares and securities 

031 Merchandise Export Commodities - Raw Jute 

032 Merchandise Export Commodities - Jute Products 

033 Merchandise Export Commodities – Tea 

48 of 92

034 Merchandise Export Commodities – Others 

036 Merchandise Import Commodities - Industrial Machineries 

037 Merchandise Import Commodities - Other Machineries 

038 Merchandise Import Commodities – Others 

039 Merchandise Other Commodities (Other than Export & Import Commodities) 

040 Machinery with other fixed Assets and financial obligations (Insurance Policies, Savings 

Certificates, Bank Deposits etc.) 

050 Real estate with financial obligation 

060 Financial obligations only (e.g. Insurance Policies, Savings Certificates, Bank deposits, etc.) 

071 Miscellaneous - Crops / Stock of crops hypothecation 

080 Without any security 

5.4.15 TABLE ID 

Used in the Subject Data table, in the “Body for Record Type: Personal Data” section to indicate 

what document is being provided (if any). Please note: National ID number is its own separate 

field and therefore does not appear in this list. 

Table ID 


1 Passport 

2 Driving Licence 

3 Commissioner Certificate 

5.4.16 TABLE SHAREHOLDERS TYPES 

Used in the Subject Data table, in the “Body for Record Type: Company-Shareholders” section to 

indicate the role that a specific individual has with a specific company. The roles indicated in this 

list are the only ones that can be provided. 

Table Shareholders Types 


1 Chairman 

2 Managing director 

3 Sponsor director 

4 Elected director 

5 Nominated director (by Govt) 

6 Nominated director (by Pvt. Institution) 

7 Partner 

5.4.17 TABLE SECTOR TYPES 

Used in the Subject Data table, in the “Body for Record Type: Personal Data”, and “Body for 

Record Type: Individual Concern”, and “Body for Record Type: Companies” as an attribute to the 

specific Subject. 

Sector Types 


1 Public 

9 Private 

49 of 92

5.4.18 TABLE SECTOR CODE 

Used in the Subject Data table, in the “Body for Record Type: Personal Data”, and “Body for 

Record Type: Individual Concern”, and “Body for Record Type: Companies” sections to indicate 

whether the specific Subject is a Public or Private entity. 

Table Sector code 


111000 Food Ministry (Including food divisions/directorates) 

112000 Presidency, Prime Minister's Office, Other Ministries, Parliament, Judiciary, all 

Directorates and Departments 

112100 Bangladesh Post Office (except Savings Bank Scheme) 

112200 Bangladesh Post Office Saving Bank Scheme 

113101 National Curriculum and Text Book Board 

113102 Bangladesh Madrasha Education Board 

113103 Bangladesh Technical Education Board 

113105 Board of Intermediate and Secondary Education, Dhaka 

113106 Board of Intermediate and Secondary Education, Chittagong 

113107 Board of Intermediate and Secondary Education, Rajshahi 

113108 Board of Intermediate and Secondary Education, Jessore 

113109 Board of Intermediate and Secondary Education, Comilla 

113110 Board of Intermediate and Secondary Education, Sylhet 

113111 Board of Intermediate and Secondary Education, Barisal 

113201 Government Schools, Madrashas, Colleges & University Colleges (Except Medical 

Colleges & Institute of Technologies) 

113202 Cadet Colleges 

113204 Bangladesh National University 

113205 Bangladesh Open University 

113206 Medical/Dental Colleges 

113207 Institute of Technologies (Including Polytechnic Institutes) 

113208 Bangladesh University of Engineering & Technology 

113209 Bangabandhu Sheikh Mujib Medical University (BSMMU) 

113210 Dhaka University 

113211 Rajshahi University 

113212 Chittagong University 

113213 Jahangirnagar University 

113214 Khulna University 

113215 Shah Jalal Science & Technology University 

113216 Mymensingh Agricultural University 

113217 Islamic University, Kushtia 

113218 Dhaka University of Engineering and Technology, Gazipur 

113219 Chittagong University of Engineering and Technology 

113220 Khulna University of Engineering and Technology 

113221 Rajshahi University of Engineering and Technology 

113222 Bangabandhu Sheikh Mujibur Rahman Agricultural University, Gazipur 

113223 Shere-e-Bangla Agricultural University, Sherebangla nagar 

113224 Haji Danesh Agricultural University, Dinajpur 

113225 Patuakhali Agricultural University 

113249 Other Public Institutes/Universities 

113301 Bangladesh Academy of Rural Development (BARD), Comilla 

113302 Regional Academy of Rural Development (RARD), Bogra 

50 of 92

113303 Bangla Academy 

113304 Bangladesh Shilpakala Academy 

113305 Islamic Foundation, Bangladesh 

113306 Bangladesh Agricultural Research Institute 

113307 Bangladesh Council of Scientific & Industrial Research 

113308 Bangladesh Rice Research Institute 

113309 Bangladesh Standard Control and Testing Institution 

113310 Bangladesh Central Public Library 

113311 Bangladesh National Museum 

113312 Bangladesh Veterinary Council 

113313 Foreign Service Academy 

113314 National Institute of Population, Research & Training 

113315 Institute of Public health and Nutrition 

113316 National Institute of Cardiovascular Diseases 

113317 National Institute of Preventive & Social Medicine (NIPSOM) 

113318 Institute of Public Health And Hospital 

113319 National Institute of Disease of Chest & Hospital (NIDCH) 

113320 National Inst.of Ophthalmology 

113321 National Inst.of Traumatology & Orthopaedic Rehabilitation (NITOR) 

113399 Other Councils/Institutes 

113401 Bangladesh Atomic Energy Commission 

113402 Bangladesh Agricultural Development Corp. 

113403 Hill tracts Development Board, Chittagong 

113404 Prime Minister's Relief Fund 

113405 Rajdhani Unnayan Kartreepaksha (RAJUK) 

113406 Chittagong Development Authority 

113407 Khulna Development Authority 

113408 Rajshahi Development Authority 

113409 Bangladesh Handloom Board 

113410 Bangladesh Sericulture Board 

113411 Export Promotion Bureau 

113412 Bangladesh Rural Development Board (BRDB) 

113413 Jamuna Multipurpose Bridge Authority 

113414 Privatisation Commission 

113415 Water Resources Planning Organisation (WAPRO) 

113416 Varendra Multipurpose Development Authority, Rajshahi 

113417 Security Printing Press Corporation 

113418 Greater Dhaka Transport Planning & Co-ordination Board 

113419 Chittagong Hill Tracts Local Council 

113420 Chittagong Hill Tracts Dist. Council, Rangamati 

113421 Chittagong Hill Tracts Dist. Council, Khagrachori 

113422 Chittagong Hill Tracts Dist.Council,Bandarban 

113423 Bangladesh Overseas Employment Service Ltd. (BOESEL) 

113424 National Housing Authority 

113425 Haor And Marsh Development Authority 

113426 Executive Cell, BEPZA 

113499 All other Boards / Centres 

113501 Bangladesh Television 

113502 Bangladesh Sangbad Sangstha 

113503 Bangladesh Betar 

51 of 92

122100 Bangladesh Textile Mills Corporation & Related Enterprises 

122210 Sugar Mills 

122220 Food and Allied Industries 

122310 Fertilizer, Chemical & Pharmaceutical Industries 

122320 Paper and Paper Board Industries 

122410 Steel Mills 

122420 Engineering and Ship Building Industries 

122510 Bangladesh Jute Mills Corporation and Related Enterprises 

122610 Bangladesh Petroleum Corporation & related enterprises 

122620 Bangladesh Oil, Gas & Mineral Corporation & related enterprises 

122700 Bangladesh Power Development Board 

122810 Bangladesh Biman Corporation 

122820 Bangladesh Shipping Corporation 

122901 Trading Corporation of Bangladesh 

122902 Bangladesh Railway 

122903 Bangladesh Telegraph & Telephone Board 

122904 Bangladesh Road Transport Corporation 

122905 Bangladesh Forest Industries Development Corporation 

122999 Others 

123110 Bangladesh Fisheries Development Corporation 

123120 Bangladesh Tea Board 

123210 Bangladesh Inland Water Transportation Authorigy (BIWTA) 

123220 Bangladesh Inland Water Transportation Corporation (BIWTC) 

123310 Bangladesh Water Development Board 

123320 Dhaka WASA 

123330 Chittagong WASA 

123390 Others 

123410 Rural Electrification Board 

123415 Dhaka Electric Supply Authority 

123420 Dhaka Electric Supply Company 

123510 Chittagong Port Authority 

123520 Mongla Port Authority 

123610 Bangladesh Small & Cottage Industries Crop. 

123701 Bangladesh Parjatan Corporation 

123702 Bangladesh Filim Development Corporation 

123704 Civil Aviation Authority of Bangladesh 

123705 Bangladesh Freedom Fighters Welfare Trust 

123706 Telephone Shilpa Sangstha 

123707 Bangladesh Cable Industries Corporation 

123708 Bangladesh Tannery Industries Corporation 

123709 Bangladesh Services Ltd. 

123710 Hotels International Ltd.(Hotels having status 3 Stars & above) 

123711 Dock Labour Management Board, Chittagong 

123712 Dock Labour Management Board, Bagherhat 

123799 Others 

124100 District Council 

124200 Municipal/City Corporation 

124300 Thana/Upazila Parishad 

124400 Union Parishad 

124500 Gram Parishad 

52 of 92

121710 Ansar-VDP Development Bank 

121720 Karma Sangsthan Bank (Employment Bank) 

121750 Others 

121100 Bangladesh House Building Finance Corporation (HBFC) 

121300 Investment Corporation of Bangladesh (ICB) 

121501 Infrastructure Development Company 

121510 Saudi-Bangladesh Industrial & Agricultural Investment Company (SABINCO) Ltd. 

121599 Others 

121600 Sadharan Bima Corporation 

121700 Jiban Bima Corporation 

121799 Others 

901001 Agricultural Farmers 

901002 Fishing Professionals 

901003 Dairy Farmers 

901004 Poultry Farmers 

902110 Jute Milles 

902111 Printing & Dyeing Industries 

902112 Spinning Mills 

902113 Weaving Mills 

902114 Coconut Oil Mills 

902115 Tobacco Processing Industries 

902116 Cosmetics & Toiletries Industries 

902117 Rubber And Plastic Industries 

902118 Rice/ Flour/Pulse Mills 

902119 Leather and Leather Products Manf. Industries 

902120 Textile Mills 

902121 Paper and Paper Products Manf. Industries 

902122 Wood and Wood Products Manf. Industries 

902123 Milk Processing Industries 

902124 Food Processing Industries (Including Agro-based Industries) 

902125 Garments Factories 

902126 Hosiery Factories 

902127 Pharmaceutical Industries 

902128 Salt Industries 

902129 Tea Processing Industries 

902130 Chemical and Chemical Products (Other than Ferilizer) Industries 

902131 Cement Factories 

902132 Ceramic Industries 

902133 Bricks and Sand Factories 

902134 Glass and Glassware Products Factories 

902135 Edible Oil Mills 

902136 Soaps & Detergents Factories 

902137 Steel Engineering & Metallic Products Industries 

902138 Assembling Industries 

902139 Fish Processing Industry 

902141 Fertilizer Company 

902190 Others 

902210 Cottage Industries 

902215 Saw Mills 

902220 Handloom Factories 

53 of 92

902225 Garments Factories 

902226 Hosiery Factories 

902230 Handicrafts Factories 

902235 Wood and Wood Products Factories 

902240 Other Factories 

902310 Electricity Companies 

902311 LP Gas Companies 

902312 Oxyzen Gas Companies 

902313 Other Gas Companies 

902319 Others 

902410 Entertainment (Cinema, Amusement Park etc.) Services 

902420 Hospitals & Clinics 

902430 IT Services (Including Cyber Cafes) 

902440 Courier Services 

902450 Hotels and Restaurants 

902451 Photo Studioes 

902452 Travel Agencies 

902453 Cold-Storages 

902454 Beauty Parlours / Saloons 

902490 Others 

903010 Importers 

903020 Exporters 

903030 Importers and Exporters 

903040 Whole Sale Traders 

903050 Retail Traders 

903090 Others 

904001 Road Transport (including Railway) 

904002 Water Transport 

904003 Air Transport 

905000 Construction Companies 

905100 Publishing Industries 

905200 Telephone Companies 

905500 Housing Companies / Societies 

906000 Storage Companies (Other than cold storage) 

907601 Newspaper 

907602 Television 

907603 Radio 

908100 Private Schools, Colleges, University Colleges & Madrashas 

908200 Medical & Dental Colleges 

908300 Private Universities 

908400 Private Institute of IT 

908900 Others 

909200 Leasing Companies (Depository) 

909300 Central Co-operative Bank 

909400 Land Mortgage Co-operative Bank 

909500 Other Co-operative Banks/Societies 

909600 Grameen Bank 

909699 Others 

909210 Investment Companies 

909220 Leasing Companies (Non-depository) 

54 of 92

909299 Others 

909100 Insurance Companies 

909199 Others 

909700 Money Changers 

909799 Others 

910000 Professionals and Self-employed Persons (Such as Doctors, Lawyers, Contractors, Taxi 

Drivers etc.) 

910500 Wage & Salary Earners (Working abroad) 

911000 Wage & Salary Earners (Working in the country) 

912050 Foreign Individuals 

912051 Toreign Offices / Enterprises / Companies / Farms 

914051 Mosques 

914052 Temples, Churches & the like 

914053 Sports Clubs 

914054 Other clubs 

914055 Theatre & Cultural Organisations 

914056 Political Parties 

914057 Trade Unions 

914058 District / Upazilla Associations 

914059 Professional (Doctors, Engineers, Statisticians, Economists etc.) Associations 

914060 Chambers of Industries 

914061 Other Associations, n.e.s. 

914062 Trust fund & Other Non-profit Organisations 

914063 Non Govt. Organisations (ASA, BRAC, PROSHIKA etc.) 

915050 Other Local Individuals 

915051 Other Local Offices/Enterprises/Companies/Farms 

5.4.19 TABLE LEGAL FORMS 

These are used in Subject Data - Body for Record Type: Individual Concern and Body for Record 

Type: Companies to indicate the legal form of the entity. 

Legal forms 


1 Proprietorship 

2 Partnership 

3 Private Ltd. Co 

4 Public Ltd. Co. 

5 Co-operative 

6 Public sector 

7 Multinational 

8 Others 

5.4.20 TABLE CONTRACT STATUS 

Banks are required to provide the Contract Status from the table below for each Contract based 

on the instructions of Bangladesh Bank. 

Table contract Status 

Status planned only for instalment/not instalment contract/cards 

55 of 92


blank Unclassified (UC) 

M Special mentioned accounts (SMA) 

S Substandard (SS) 

D Doubtful (DF) 

B Bad/loss (BL) 

W Bad/loss/Write-off (BLW) 

5.4.21 TABLE CONTRACT TYPE 

Used in Contract Data - Body for Record Type: General information for all types of Financing to 

indicate what type of specific Contract you are providing from the following list. 

Table contract Type 

Value Description(EN) 

Instalment contracts 

MG 

Mortgage loan 

DI 

Demand Loan (Instalment repayment) 

PI 

Packing Credit (Instalment repayment) 

TL 

Term Loan 

PS 

Partially Secured Term Loan 

FL 

Financial Leasing 

OL 

Operational Leasing 

BM 

Bai-Muazzal (Real Estate) 

HP 

Hire-Purchase 

HS 

Hire-Purchase under shirkatul Meelk 

IJ 

Ijara (Lease Finance) 

BI 

Bai-Muazzal (Instalment Payment) 

OI 

Other instalment contract 

Credit Cards 

RV 

Revolving Credit 

CR 

Credit Card (Revolving) 

CG 

Charge Card (Payable in full each month) 

Non instalment contracts 

OD 

Overdraft 

BL 

PAD/BLC/BE loan against doc/bills 

CP 

Cash Credit against Pledge 

CH 

Cash Credit against Hypothecation 

LT 

Loan Against Imported Merchandise (LTR) 

LI 

Loan Against Imported Merchandise (LIM) 

DN 

Demand Loan (Not Installment) 

EX 

Export Credit 

FB 

Export loan against Foreign Bill Purchased 

LB 

Export loan against Local Bill Purchased 

WK 

Working capital financing 

GU 

Guarantee (non funded) 

LC 

Letter of credit (non funded) 

OF 

Other indirect facility (non funded) 

PN 

Packing Credit (Not Installment) 

MB 

Murabaha Bills, Murabaha Bill of Exchange (General) Import Bills 

56 of 92

BU 

MC 

BC 

BB 

MS 

TR 

PH 

MP 

MT 

FI 

BS 

PC 

OP 

FN 

FP 

MD 

PF 

QA 

ON 

Bai-Murabaha 

Musharaka on consigment basis 

Bai-Murabaha-commercial 

Bai-Muazzal; Bai-Muazzal WES/Bills 

Musharaka (General) 

Bai-Murabaha-TR 

Musharaka (Local Purchase-Hypo) 

Murabaha Post Import (MPI) 

Murabaha Post Import Trust Receipt (MPITR) 

Finance against Imported Merchandise (FIM) 

Musharaka Pre-shipment, Bai-Salam 

Bai-Muazzal Pre-shipment Credit 

Any other Pre-shipment Credit 

Foreign Bill Negotiation (FBN) 

Foreign Bill Purchase (FBP) 

Musharaka Documentary Bills(MDB) 

Post-shipment Finance 

Quard (All types) 

Other non instalment contract 

5.4.22 TABLE ECONOMIC PURPOSE 

Used in the Contract Data to provide the economic purpose of each specific Contract. 

Table Economic purpose 


1111 Paddy 

1112 Wheat 

1113 Cotton 

1114 Jute 

1115 Tobacco 

1116 Sugar cane 

1117 Flower 

1119 Others 

1121 Tea 

1122 Rubber 

1123 Sericulture 

1124 Horticulture (Mango, Banana, Pine apple, Coconut etc.) 

1129 Others 

1131 Shallow/Deep Tube Well 

1132 Low Lift Pumps/Other Pumps 

1133 Tractors/Power Tillers 

1134 Ploughing Cattle 

1139 Others (Manual Tube well/ Bullock Carts etc.) 

1140 Agricultural Fertilizers and Pesticides 

1151 Dairy farming 

1152 Poultry Farming 

1153 Purchase of Cattle (Poverty Alleviation Programme) 

1159 Others 

1210 Inland Fishing (Other than Shrimp Culture) Including pond fishing 

57 of 92

1220 Marine Fishing 

1240 Shrimp Culture 

1290 Other Fishing 

1300 Forestry & Logging 

2111 Rice, Flour, Oil and Pulse mills 

2112 Fish Canning, Freezing and Preservation units 

2113 Sugar Mills 

2114 Manufacturing units of hydrogenated oils, Vanaspati, Ghee and Edible oils & fats 

2115 Prawn/Shrimp Processing 

2116 Tea Processing 

2117 Salt Manufacturing and Processing Industries 

2119 Others 

2121 Distilleries, Beverage and Soft Drink Manufactures 

2122 Tobacco Processing and Manufacturing (Bidi, Cigarettes, etc.) 

2123 Juice Processing 

2124 Milk and Milk Foods Processing 

2125 Other Food Processing 

2129 Others 

2131 Cotton (Ginning, Pressing and Baling) 

2132 Cotton Textiles (Spinning, Weaving, Dyeing, Printing etc.) 

2133 Jute (Pressing, Baling and Yarn) 

2134 Jute Mills (Carpet, Bags and Textiles) 

2135 Silk and Synthetic Fibres (Rayon, Nylon, Art silk etc.) 

2136 Wearing Apparel 

2139 Others 

2141 Leather Processing and Tanning 

2142 Manufactures of leather goods (including footwear) 

2151 Paper and Paper Products (including paper boards) 

2152 Printing, Publishing and Allied Industries 

2153 News papers and Periodical Publications 

2161 Saw mills 

2162 Manufacturing of furniture, fixtures and wood products 

2171 Heavy Industrial Chemicals (Caustic Soda, Soda ash etc.) 

2173 Fertilizer Factories 

2174 Drugs and Pharmaceuticals 

2175 Plastic and Plastic Products 

2176 Rubber Products 

2177 Soap and Detergents 

2179 Other Chemicals and Chemical Products 

2181 Cement and Asbestos 

2182 Glass and glass Products 

2183 Ceramic Products 

2184 Bricks and Tiles 

2189 Others 

2191 Electrical Equipments and Spares 

2192 Transport Equipments and Spares 

2193 Iron and Steel Mills 

2194 Aluminium Factories 

2199 Other Metals and Metal Products 

2101 Automobiles (including CNG conversion) 

58 of 92

2102 Electric / Electronic Goods (Freeze, TV, Computer etc.) 

2201 Electricity (Generation, Supply and Distribution) 

2205 Petroleum (Refine, Supply) 

2206 Natural Gas (Elevation, Transmission and Distribution) 

2207 L.P.Gas 

2208 Oxyzen Gas 

2209 Others 

2239 Other Industries 

2211 Rice, Flour, Oil and Pulse Mills 

2212 Coconut Oil Mills 

2213 Leather and Leather Products 

2214 Paper and Paper Products ( including paper boards) 

2215 Wood and Wood Products 

2216 Dyeing and Printing 

2217 Printing, Publishing and Allied Industries 

2218 Saw Mills 

2219 Salt Manufacturing & Processing Industries 

2221 Tobacco Processing and Manufacturing (Bidi, Cigarettes etc.) 

2222 Plastic and Plastic Products 

2223 Cosmetics 

2224 Jute and Jute Goods 

2225 Livestock and Poultry Feed 

2226 Milk and Milk Products 

2227 Jam, Jelly, Pickles etc. 

2228 Ice Factory 

2229 Weaving Industry 

2249 Other Industry 


2310 Entertainment / Amusement (Cinema, Park etc.) 

2320 Hospital, Clinic and Pathology 

2330 IT Services 

2340 Courier Services 

2350 Hotel and Restaurant 

2360 Cold Storage Company 

2370 Travel Agency 

2380 Photo Studio and Color Lab 

2385 Beauty Parlour/Saloon 

2390 Other Services 

3110 Food Stuff Manufacturing and Processing Industries 

3120 Beverage and Tobacco Industries 

3131 Jute industries 

3132 Cotton and Wearing Apparel Industries 

3140 Leather and Leather Products 

3150 Manufacturing of Paper & Paper Products and Printing 

3160 Manufacturing of Wood and Wood Products including pulp 

3170 Manufacturing of Chemical, Chemical Products, Plastic Products and Rubber Products 

3171 Petroleum Refinery 

3172 Pharmaceutical Industries 

3180 Manufacturing of Non-metallic Mineral Products 

3190 Manufacturing of Engineering, Basic Metal and Metal Products 

59 of 92

3192 Edible Oil Industries 

3195 Soap and Detergent Factories 

3161 Assembling Industry 

3197 Electricity Industry 

3198 Gas Industry 

3199 Other Industries 

3210 Small Scale Industries 


3310 Service Industry 

4100 Housing Societies / Companies 

4210 Urban Housing 

4220 Rural Housing 

4230 Road Construction / Repairing 

4240 Apartment / House Renovation 

4300 Other than Housing 

5300 Water-works 

5310 Sanitary Services 

6100 Road Transport (Bus, Trucks, Diesel Engines, Auto Rickshaw, Taxicab etc.) 

6200 Water Transport (Launch, Ferry, Steamer etc.) 

6300 Air transport 

6400 Public Utilities (Telephone, Telegram, Telex, Fax etc.) 

7100 Ware Housing 

7200 Cold-Storage 

8110 Jute Trading 

8111 Wholesale Trading 

8112 Retail Trading 

8120 Others 

8210 Jute 

8220 Paddy 

8230 Wheat 

8290 Others 

8311 Raw Jute 

8312 Jute Goods 

8320 Tea 

8330 Hides and Skins 

8340 Ready-made Garments 

8380 Others (Other than non-traditional items) 

8391 Fish, Shrimps, Prawns etc. 

8392 Handicrafts 

8399 Other non-traditional items 

8401 Food Stuffs 

8402 Petroleum and Petroleum Products 

8403 Machineries and Implements 

8404 Textile and Textile Products 

8405 Electric and Electronic goods & Spares 

8406 Sanitary Goods Including Tiles, Stones & Clinkers 

8407 Cosmetics & Crockeries 

8408 Medicine and Surgical Instruments 

8410 New Automobiles and Spares 

8411 Reconditioned Automobiles 

60 of 92

8412 Chemicals (except Medicine) 

8413 Iron and Steel Products 

8414 Paper and Printed Papers 

8415 Computer and Accessories 

8416 Wood & Logging 

8417 Plastic & Plastic Products 

8418 Leather Goods 

8419 Poultry feeds 

8420 Cattle feeds 

8499 Others 

8501 Lease Financing 

8507 Leasing 

9200 Private Welfare and Development Activities 

9300 Advances for Special Credit Program (Special Economic Zone, EPZ, Youth Development 

etc.) 

9400 Advances for Co-operative banks / Societies 

9500 Advances for Professional Services (Such as Doctors, Engineers and Other technically 

qualified persons) 

9600 Swanirvar 

9700 Poverty Alleviation Program 

9800 Ship-Breaking 

9810 Flat Purchase 

9820 Consumer Goods (Motor Car/Cycle, TV, Freeze, Computer etc.) Purchase 

9830 Purchases Through Credit Cards 

9840 Meeting up of Educational Expenses 

9850 Meeting up of Medical Treatment Cost 

9860 Meeting up of Marriage Expenses 

9870 Land Purchase 

9900 Other Occupations / Activities 

5.4.23 TABLE COUNTRY CODES 

Table Country Codes 

Description 

AFGHANISTAN 

ALAND ISLANDS 

ALBANIA 

ALGERIA 

AMERICAN SAMOA 

ANDORRA 

ANGOLA 

ANGUILLA 

ANTARCTICA 

ANTIGUA AND BARBUDA 

ARGENTINA 

ARMENIA 

ARUBA 

AUSTRALIA 

AUSTRIA 

61 of 92 

Value 

AF 

AX 

AL 

DZ 

AS 

AD 

AO 

AI 

AQ 

AG 

AR 

AM 

AW 

AU 

AT

AZERBAIJAN 

BAHAMAS 

BAHRAIN 

BANGLADESH 

BARBADOS 

BELARUS 

BELGIUM 

BELIZE 

BENIN 

BERMUDA 

BHUTAN 

BOLIVIA 

BOSNIA AND HERZEGOVINA 

BOTSWANA 

BOUVET ISLAND 

BRAZIL 

BRITISH INDIAN OCEAN TERRITORY 

BRUNEI DARUSSALAM 

BULGARIA 

BURKINA FASO 

BURUNDI 

CAMBODIA 

CAMEROON 

CANADA 

CAPE VERDE 

CAYMAN ISLANDS 

CENTRAL AFRICAN REPUBLIC 

CHAD 

CHILE 

CHINA 

CHRISTMAS ISLAND 

COCOS (KEELING) ISLANDS 

COLOMBIA 

COMOROS 

CONGO 

CONGO, THE DEMOCRATIC REPUBLIC OF THE 

COOK ISLANDS 

COSTA RICA 

CÔTE D'IVOIRE 

CROATIA 

CUBA 

CYPRUS 

CZECH REPUBLIC 

DENMARK 

DJIBOUTI 

DOMINICA 

DOMINICAN REPUBLIC 

EAST TIMOR 

ECUADOR 

EGYPT 

AZ 

BS 

BH 

BD 

BB 

BY 

BE 

BZ 

BJ 

BM 

BT 

BO 

BA 

BW 

BV 

BR 

IO 

BN 

BG 

BF 

BI 

KH 

CM 

CA 

CV 

KY 

CF 

TD 

CL 

CN 

CX 

CC 

CO 

KM 

CG 

CD 

CK 

CR 

CI 

HR 

CU 

CY 

CZ 

DK 

DJ 

DM 

DO 

TP 

EC 

EG 

62 of 92

EL SALVADOR 

EQUATORIAL GUINEA 

ERITREA 

ESTONIA 

ETHIOPIA 

FALKLAND ISLANDS (MALVINAS) 

FAROE ISLANDS 

FIJI 

FINLAND 

FRANCE 

FRENCH GUIANA 

FRENCH POLYNESIA 

FRENCH SOUTHERN TERRITORIES 

GABON 

GAMBIA 

GEORGIA 

GERMANY 

GHANA 

GIBRALTAR 

GREECE 

GREENLAND 

GRENADA 

GUADELOUPE 

GUAM 

GUATEMALA 

GUERNSEY ISLANDS 

GUINEA 

GUINEA-BISSAU 

GUYANA 

HAITI 

HEARD ISLAND AND MCDONALD ISLANDS 

HOLY SEE (VATICAN CITY STATE) 

HONDURAS 

HONG KONG 

HUNGARY 

ICELAND 

INDIA 

INDONESIA 

IRAN, ISLAMIC REPUBLIC OF 

IRAQ 

IRELAND 

ISRAEL 

ITALY 

JAMAICA 

JAPAN 

JERSEY, ISLANDS 

JORDAN 

KAZAKSTAN 

KENYA 

KIRIBATI 

SV 

GQ 

ER 

EE 

ET 

FK 

FO 

FJ 

FI 

FR 

GF 

PF 

TF 

GA 

GM 

GE 

DE 

GH 

GI 

GR 

GL 

GD 

GP 

GU 

GT 

GG 

GN 

GW 

GY 

HT 

HM 

VA 

HN 

HK 

HU 

IS 

IN 

ID 

IR 

IQ 

IE 

IL 

IT 

JM 

JP 

JE 

JO 

KZ 

KE 

KI 

63 of 92

KOREA, DEMOCRATIC PEOPLE'S REPUBLIC OF 

KOREA, REPUBLIC OF 

KUWAIT 

KYRGYZSTAN 

LAO PEOPLE'S DEMOCRATIC REPUBLIC 

LATVIA 

LEBANON 

LESOTHO 

LIBERIA 

LIBYAN ARAB JAMAHIRIYA 

LIECHTENSTEIN 

LITHUANIA 

LUXEMBOURG 

MACAU 

MACEDONIA, THE FORMER YUGOSLAV REPUBLIC OF 

MADAGASCAR 

MALAWI 

MALAYSIA 

MALDIVES 

MALI 

MALTA 

MAN ISLAND 

MARSHALL ISLANDS 

MARTINIQUE 

MAURITANIA 

MAURITIUS 

MAYOTTE 

MONTENEGRO 

MEXICO 

MICRONESIA, FEDERATED STATES OF 

MOLDOVA, REPUBLIC OF 

MONACO 

MONGOLIA 

MONTSERRAT 

MOROCCO 

MOZAMBIQUE 

MYANMAR 

NAMIBIA 

NAURU 

NEPAL 

NETHERLANDS 

NETHERLANDS ANTILLES 

NEW CALEDONIA 

NEW ZEALAND 

NICARAGUA 

NIGER 

NIGERIA 

NIUE 

NORFOLK ISLAND 

NORTHERN MARIANA ISLANDS 

KP 

KR 

KW 

KG 

LA 

LV 

LB 

LS 

LR 

LY 

LI 

LT 

LU 

MO 

MK 

MG 

MW 

MY 

MV 

ML 

MT 

IM 

MH 

MQ 

MR 

MU 

YT 

ME 

MX 

FM 

MD 

MC 

MN 

MS 

MA 

MZ 

MM 

NA 

NR 

NP 

NL 

AN 

NC 

NZ 

NI 

NE 

NG 

NU 

NF 

MP 

64 of 92

NORWAY 

OMAN 

PAKISTAN 

PALAU 

PALESTINIAN TERRITORY, OCCUPIED 

PANAMA 

PAPUA NEW GUINEA 

PARAGUAY 

PERU 

PHILIPPINES 

PITCAIRN 

POLAND 

PORTUGAL 

PUERTO RICO 

QATAR 

RÉUNION 

ROMANIA 

RUSSIAN FEDERATION 

RWANDA 

SAINT BARTHÉLEMY 

SAINT HELENA 

SAINT KITTS AND NEVIS 

SAINT LUCIA 

SAINT MARTIN (FRENCH PART) 

SAINT PIERRE AND MIQUELON 

SAINT VINCENT AND THE GRENADINES 

SAMOA 

SAN MARINO 

SAO TOME AND PRINCIPE 

SAUDI ARABIA 

SENEGAL 

SERBIA & MONTENEGRO 

SERBIA 

SEYCHELLES 

SIERRA LEONE 

SINGAPORE 

SLOVAKIA 

SLOVENIA 

SOLOMON ISLANDS 

SOMALIA 

SOUTH AFRICA 

SOUTH GEORGIA AND THE SOUTH SANDWICH ISLANDS 

SPAIN 

SRI LANKA 

SUDAN 

SURINAME 

SVALBARD AND JAN MAYEN 

SWAZILAND 

SWEDEN 

SWITZERLAND 

NO 

OM 

PK 

PW 

PS 

PA 

PG 

PY 

PE 

PH 

PN 

PL 

PT 

PR 

QA 

RE 

RO 

RU 

RW 

BL 

SH 

KN 

LC 

MF 

PM 

VC 

WS 

SM 

ST 

SA 

SN 

CS 

RS 

SC 

SL 

SG 

SK 

SI 

SB 

SO 

ZA 

GS 

ES 

LK 

SD 

SR 

SJ 

SZ 

SE 

CH 

65 of 92

SYRIAN ARAB REPUBLIC 

TAIWAN, PROVINCE OF CHINA 

TAJIKISTAN 

TANZANIA, UNITED REPUBLIC OF 

THAILAND 

TIMOR-LESTE 

TOGO 

TOKELAU 

TONGA 

TRINIDAD AND TOBAGO 

TUNISIA 

TURKEY 

TURKMENISTAN 

TURKS AND CAICOS ISLANDS 

TUVALU 

UGANDA 

UKRAINE 

UNITED ARAB EMIRATES 

UNITED KINGDOM 

UNITED STATES 

UNITED STATES MINOR OUTLYING ISLANDS 

URUGUAY 

UZBEKISTAN 

VANUATU 

Vatican City State see HOLY SEE 

VENEZUELA 

VIET NAM 

VIRGIN ISLANDS, BRITISH 

VIRGIN ISLANDS, U.S. 

WALLIS AND FUTUNA 

WESTERN SAHARA 

YEMEN 

YUGOSLAVIA 

Zaire see CONGO, THE DEMOCRATIC REPUBLIC OF THE 

ZAMBIA 

ZIMBABWE 

SY 

TW 

TJ 

TZ 

TH 

TL 

TG 

TK 

TO 

TT 

TN 

TR 

TM 

TC 

TV 

UG 

UA 

AE 

GB 

US 

UM 

UY 

UZ 

VU 

VE 

VN 

VG 

VI 

WF 

EH 

YE 

YU 

ZM 

ZW 

5.4.24 TABLE CURRENCY CODES 

Table Currency Codes 


AED United Arab Emirates dirham 

AFN Afghani 

ALL Lek 

AMD Armenian dram 

ANG Netherlands Antillean guilder 

AOA Kwanza 

ARS Argentine peso 

AUD Australian dollar 

66 of 92

AWG 

AZN 

BAM 

BBD 

BDT 

BGN 

BHD 

BIF 

BMD 

BND 

BOB 

BOV 

BRL 

BSD 

BTN 

BWP 

BYR 

BZD 

CAD 

CDF 

CHE 

CHF 

CHW 

CLF 

CLP 

CNY 

COP 

COU 

CRC 

CUC 

CUP 

CVE 

CZK 

DJF 

DKK 

DOP 

DZD 

EEK 

EGP 

ERN 

ETB 

EUR 

FJD 

FKP 

GBP 

GEL 

GHS 

GIP 

GMD 

GNF 

Aruban guilder 

Azerbaijanian manat 

Convertible marks 

Barbados dollar 

Bangladeshi taka 

Bulgarian lev 

Bahraini dinar 

Burundian franc 

Bermudian dollar (customarily known as Bermuda dollar) 

Brunei dollar 

Boliviano 

Bolivian Mvdol (funds code) 

Brazilian real 

Bahamian dollar 

Ngultrum 

Pula 

Belarusian ruble 

Belize dollar 

Canadian dollar 

Franc Congolais 

WIR euro (complementary currency) 

Swiss franc 

WIR franc (complementary currency) 

Unidad de Fomento (funds code) 

Chilean peso 

Chinese Yuan 

Colombian peso 

Unidad de Valor Real 

Costa Rican colon 

Cuban convertible peso 

Cuban peso 

Cape Verde escudo 

Czech Koruna 

Djibouti franc 

Danish krone 

Dominican peso 

Algerian dinar 

Kroon 

Egyptian pound 

Nakfa 

Ethiopian birr 

euro 

Fiji dollar 

Falkland Islands pound 

Pound sterling 

Lari 

Cedi 

Gibraltar pound 

Dalasi 

Guinea franc 

67 of 92

GTQ Quetzal 

GYD Guyana dollar 

HKD Hong Kong dollar 

HNL Lempira 

HRK Croatian kuna 

HTG Haiti gourde 

HUF Forint 

IDR Rupiah 

ILS Israeli new sheqel 

INR Indian rupee 

IQD Iraqi dinar 

IRR Iranian rial 

ISK Iceland krona 

JMD Jamaican dollar 

JOD Jordanian dinar 

JPY Japanese yen 

KES Kenyan shilling 

KGS Som 

KHR Riel 

KMF Comoro franc 

KPW North Korean won 

KRW South Korean won 

KWD Kuwaiti dinar 

KYD Cayman Islands dollar 

KZT Tenge 

LAK Kip 

LBP Lebanese pound 

LKR Sri Lanka rupee 

LRD Liberian dollar 

LSL Lesotho loti 

LTL Lithuanian litas 

LVL Latvian lats 

LYD Libyan dinar 

MAD Moroccan dirham 

MDL Moldovan leu 

MGA Malagasy ariary 

MKD Denar 

MMK Kyat 

MNT Tugrik 

MOP Pataca 

MRO Ouguiya 

MUR Mauritius rupee 

MVR Rufiyaa 

MWK Kwacha 

MXN Mexican peso 

MXV Mexican Unidad de Inversion (UDI) (funds code) 

MYR Malaysian ringgit 

MZN Metical 

NAD Namibian dollar 

NGN Naira 

68 of 92

NIO 

NOK 

NPR 

NZD 

OMR 

PAB 

PEN 

PGK 

PHP 

PKR 

PLN 

PYG 

QAR 

RON 

RSD 

RUB 

RWF 

SAR 

SBD 

SCR 

SDG 

SEK 

SGD 

SHP 

SLL 

SOS 

SRD 

STD 

SYP 

SZL 

THB 

TJS 

TMT 

TND 

TOP 

TRY 

TTD 

TWD 

TZS 

UAH 

UGX 

USD 

USN 

USS 

UYU 

UZS 

VEF 

VND 

VUV 

WST 

Cordoba oro 

Norwegian krone 

Nepalese rupee 

New Zealand dollar 

Rial Omani 

Balboa 

Nuevo sol 

Kina 

Philippine peso 

Pakistan rupee 

Zloty 

Guarani 

Qatari rial 

Romanian new leu 

Serbian dinar 

Russian rouble 

Rwanda franc 

Saudi riyal 

Solomon Islands dollar 

Seychelles rupee 

Sudanese pound 

Swedish krona/kronor 

Singapore dollar 

Saint Helena pound 

Leone 

Somali shilling 

Surinam dollar 

Dobra 

Syrian pound 

Lilangeni 

Baht 

Somoni 

Manat 

Tunisian dinar 

Pa'anga 

Turkish lira 

Trinidad and Tobago dollar 

New Taiwan dollar 

Tanzanian shilling 

Hryvnia 

Uganda shilling 

US dollar 

United States dollar (next day) (funds code) 

United States dollar (same day) (funds code) 

Peso Uruguayo 

Uzbekistan som 

Venezuelan bolívar fuerte 

Vietnamese dng 

Vatu 

Samoan tala 

69 of 92

XAF 

XAG 

XAU 

XBA 

XBB 

XBC 

XBD 

XCD 

XDR 

XFU 

XOF 

XPD 

XPF 

XPT 

XTS 

XXX 

YER 

ZAR 

ZMK 

ZWL 

CFA franc BEAC 

Silver (one troy ounce) 

Gold (one troy ounce) 

European Composite Unit (EURCO) (bond market unit) 

European Monetary Unit (E.M.U.-6) (bond market unit) 

European Unit of Account 9 (E.U.A.-9) (bond market unit) 

European Unit of Account 17 (E.U.A.-17) (bond market unit) 

East Caribbean dollar 

Special Drawing Rights 

UIC franc (special settlement currency) 

CFA Franc BCEAO 

Palladium (one troy ounce) 

CFP franc 

Platinum (one troy ounce) 

Code reserved for testing purposes 

No currency 

Yemeni rial 

South African rand 

Kwacha 

Zimbabwe dollar 

5.4.25 TABLE DISTRICTS 

PLEASE NOTE: This is the list of current districts in Bangladesh as of December 2009 for your 

information. IT IS NOT A Domain list, meaning that the system will not compare data in input 

with this list. 

Table Districts 

Bagerhat 

Bandarban 

Barguna 

Barishal 

Bhola 

Bogra 

Brahmanbaria 

Chandpur 

Chapinawabganj 

Chittagong 

Chuadanga 

Comilla 

Cox’s Bazar 

Dhaka 

Dinajpur 

Faridpur 

Feni 

Gaibandha 

Gazipur 

Gopalganj 

Hobiganj 

Jamalpur 

Jessore 

70 of 92

Jhalokathi 

Jinaidaha 

Joypurhat 

Khagrachari 

Khulna 

Kishoreganj 

Kurigram 

Kustia 

Lakshmipur 

Lalmonirhat 

Madaripur 

Magura 

Manikganj 

Meherpur 

Moulvibazar 

Munshiganj 

Mymensingh 

Naogaon 

Narail 

Narayanganj 

Narshingdi 

Natore 

Netrakona 

Nilphamari 

Noakhali 

Pabna 

Panchagarh 

Patuakhali 

Pirojpur 

Rajbari 

Rajshahi 

Rangamati 

Rangpur 

Satkhira 

Shariatpur 

Sherpur 

Sirajganj 

Sunamganj 

Sylhet 

Tangail 

Thakurgaon 

5.4.26 TABLE ERRORS 

This paragraph lists the errors raised by pre-check, check and acquisition phases. In particular: 

Errors of type 10 are returned only by check and acquisition phases 

Errors of type 4 are returned only by pre-check phase 

Type Code Description 

4 001 FI Code in Footer of Contract file is empty 

71 of 92

4 001 FI Code in Footer of Subject file is empty 

4 001 FI Code in Header of Contract file is empty 

4 001 FI Code in Header of Subject file is empty 

4 002 Accounting date in Footer of Contract file is empty 

4 002 Accounting date in Footer of Subject file is empty 

4 002 Accounting date in Header of Contract file is empty 

4 002 Accounting date in Header of Subject file is empty 

4 003 Production date in Footer of Contract file is empty 

4 003 Production date in Footer of Subject file is empty 

4 003 Production date in Header of Contract file is empty 

4 003 Production date in Header of Subject file is empty 

4 004 Accounting date in Footer of Contract file has an invalid format 

4 004 Accounting date in Footer of Subject file has an invalid format 

4 004 Accounting date in Header of Contract file has an invalid format 

4 004 Accounting date in Header of Subject file has an invalid format 

4 005 Production date in Footer of Contract file has an invalid format 

4 005 Production date in Footer of Subject file has an invalid format 

4 005 Production date in Header of Contract file has an invalid format 

4 005 Production date in Header of Subject file has an invalid format 

4 006 Accounting date in Footer of Contract file is not the last day of the month 

4 006 Accounting date in Footer of Subject file is not the last day of the month 

4 006 Accounting date in Header of Contract file is not the last day of the month 

4 006 Accounting date in Header of Subject file is not the last day of the month 

4 007 Accounting date in Footer of Contract file is not < current date 

4 007 Accounting date in Footer of Subject file is not < current date 

4 007 Accounting date in Header of Contract file is not < current date 

4 007 Accounting date in Header of Subject file is not < current date 

4 008 Production date in Footer of Contract file is not >= accounting date 

4 008 Production date in Footer of Subject file is not >= accounting date 

4 008 Production date in Header of Contract file is not >= accounting date 

4 008 Production date in Header of Subject file is not >= accounting date 

4 020 Code to link in Header of Contract file is empty 

4 020 Code to link in Header of Subject file is empty 

4 030 Invalid number of records field in Footer of Contract file 

4 030 Invalid number of records field in Footer of Subject file 

4 040 FI Code in Header of Subject file and Header of Contract file are different 

4 041 Accounting date in Header of Subject file and Header of Contract file are different 

4 042 Production date in Header of Subject file and Header of Contract file are different 

4 043 Code to link in Header of Subject file and Header of Contract file are different 

4 050 Contract file is empty 

4 050 Subject file is empty 

4 051 First line of Contract file is not header 

4 051 First line of Subject file is not header 

4 052 Last line of Contract file is not footer 

4 052 Last line of Subject file is not footer 

4 053 Multiple headers in Contract file 

72 of 92

4 053 Multiple headers in Subject file 

4 054 Multiple footers in Contract file 

4 054 Multiple footers in Subject file 

4 055 Line {0} is empty in Contract file 

4 055 Line {0} is empty in Subject file 

4 056 Line {0} has an invalid type in Contract file 

4 056 Line {0} has an invalid type in Subject file 

4 057 Line {0} has an invalid length in Contract file 

4 057 Line {0} has an invalid length in Subject file 

4 058 Line {0} has FI Code different from header in Contract file 

4 058 Line {0} has FI Code different from header in Subject file 

4 059 FI code in header is different from the footer one in Contract file 

4 059 FI code in header is different from the footer one in Subject file 

4 060 Accounting date in header is different from the footer one in Contract file 

4 060 Accounting date in header is different from the footer one in Subject file 

4 061 Production date in header is different from the footer one in Contract file 

4 061 Production date in header is different from the footer one in Subject file 

4 062 Number of records do not match with footer value in Contract file 

4 062 Number of records do not match with footer value in Subject file 

4 063 Line {0} has an invalid contract type in Contract File. 

4 080 FI has elaborations in status Running or Interrupted with error 

4 081 Error in Elaboration order check for FI 

4 082 The input Accounting Date is not > Accounting Date of elaborations for FI already 

existing in the system in status Running or Terminated OK or Terminated with error 

or Interrupted with error 

4 083 FI code in file header and footer is not congruent with the file name FI code 

Where {0} is line number including the header line 

Type Code Description 

10 032 MAIN ADDRESS FIELD: DISTRICT IS EMPTY 

10 044 MAIN ADDRESS FIELD: STREET AND NUMBER IS EMPTY 

10 049 ID FIELD: ID TYPE IS NOT IN THE DOMAIN 

10 077 DUE FOR RECOVERY IS NOT NUMERIC 

10 078 RECOVERY DURING THE REPORTING PERIOD IS NOT 

NUMERIC 

10 079 CUMULATIVE RECOVERY IS NOT NUMERIC 

10 080 DATE OF LAW SUIT HAS AN INVALID FORMAT 

10 081 DATE OF CLASSIFICATION HAS AN INVALID FORMAT 

10 082 NUMBER OF TIMES RESCHEDULED IS NOT NUMERIC 

10 083 ECONOMIC PURPOSE CODE IS NOT IN THE DOMAIN 

10 084 NUMBER OF DAY OF PAYMENT DELAY IS NOT IN THE 

DOMAIN 

10 085 CONTRACT REQUEST DATE IS EMPTY OR HAS AN INVALID 

FORMAT 

10 086 FI CODE OF RECORD IS DIFFERENT FROM THE FI CODE 

THAT SENT CONTRIBUTION 

10 087 FI SUBJECT CODE IS EMPTY 

10 088 FI CONTRACT CODE IS EMPTY 

10 090 CONTRACT TYPE IS NOT IN THE DOMAIN 

10 091 CONTRACT PHASE IS NOT IN THE DOMAIN 

10 092 CONTRACT STATUS IS NOT IN THE DOMAIN 

10 093 CURRENCY CODE IS NOT BDT 

10 094 CURRENCY CODE OF CREDIT IS NOT IN THE DOMAIN 

Notes 

73 of 92

10 095 CONTRACT STARTING DATE IS EMPTY OR HAS AN INVALID 

FORMAT 

10 096 CONTRACT PLANNED END DATE HAS AN INVALID FORMAT 

10 097 CONTRACT ACTUAL END DATE IS EMPTY OR HAS AN 

INVALID FORMAT 

10 098 LAST PAYMENT DATE HAS AN INVALID FORMAT 

10 100 FLAG SUBSIDIZED CREDIT IS NOT IN THE DOMAIN 

10 101 FLAG PRE-FINANCE OF LOAN IS NOT IN THE DOMAIN 

10 102 FLAG REORGANIZED CREDIT IS NOT IN THE DOMAIN 

10 104 PERSONAL GUARANTEE TYPE IS NOT IN THE DOMAIN 

10 105 REAL GUARANTEE TYPE IS NOT IN THE DOMAIN 

10 106 AMOUNT GUARANTEED BY PERSONAL GUARANTEE FORMAT 

IS NOT NUMERIC 

10 107 AMOUNT GUARANTEED BY REAL GUARANTEE FORMAT IS 

NOT NUMERIC 

10 111 TOTAL FINANCED AMOUNT FORMAT IS NOT NUMERIC 

10 112 NUMBER OF INSTALMENTS FORMAT IS NOT NUMERIC 

10 113 PERIODICITY OF PAYMENT IS NOT IN THE DOMAIN 

10 114 METHOD OF PAYMENT IS NOT IN THE DOMAIN 

10 115 MONTHLY INSTALMENT AMOUNT FORMAT IS NOT NUMERIC 

10 116 EXPIRATION DATE OF NEXT INSTALMENT HAS AN INVALID 

FORMAT 

10 117 AMOUNT OF NEXT EXPIRING INSTALMENT FORMAT IS NOT 

NUMERIC 

10 118 NUMBER OF REMAINING INSTALMENTS FORMAT IS NOT 

NUMERIC 

10 119 REMAINING AMOUNT FORMAT IS NOT NUMERIC 

10 120 NUMBER OF OVERDUE AND NOT PAID INSTALMENTS 

FORMAT IS NOT NUMERIC 

10 121 OVERDUE AND NOT PAID AMOUNT FORMAT IS NOT 

NUMERIC 

10 122 TYPE OF LEASED GOOD IS NOT IN THE DOMAIN 

10 123 VALUE OF LEASED GOOD FORMAT IS NOT NUMERIC 

10 124 FLAG NEW/USED IS NOT IN THE DOMAIN 

10 125 DATE OF MANUFACTURING HAS AN INVALID FORMAT 

10 126 CREDIT LIMIT FORMAT IS NOT NUMERIC 

10 127 DATE OF LAST CHARGE HAS AN INVALID FORMAT 

10 128 AMOUNT CHARGED IN THE MONTH IS NOT NUMERIC 

10 129 TYPE OF INSTALMENT IS NOT IN THE DOMAIN 

10 130 FLAG CARD USED IN THE MONTH IS NOT IN THE DOMAIN 

10 131 NUMBER OF TIMES CARD HAS BEEN USED IN THE MONTH 

IS NOT NUMERIC 

10 132 CREDIT LIMIT FORMAT IS NOT NUMERIC 

10 133 UTILIZATION IS NOT NUMERIC 

10 140 

Contract phase = ["LV", "TM", "TA"] and Contract starting 

date is empty 

10 141 Contract phase = ["LV", "TM", "TA"] and contract category 

is ["Instalments"] and Contract planned end date is empty 

10 142 Contract phase = ["TM", "TA"] and Contract actual end date 

10 149 

is empty 

Last payment date is not empty and File accounting Date < 

Last payment date 

10 152 Expiration Date of Next Instalment is not empty and 

Contract starting date is not empty and Contract starting 

date > Expiration Date of Next Instalment 

10 153 Expiration Date of Next Instalment is not empty and 

Contract actual end date is not empty and Expiration Date 

of Next Instalment > Contract actual end date 

For contracts that are ongoing or have been closed, 

the starting date of that contract must always be 

provided 

Please note that this date should be the date when 

the file was prepared. If the file is prepared on 

31/12/2009, there can‟t be any “Last Payment 

Dates” after such data (since if you prepared the file 

on 31/12/2009, you cannot report something that 

hasn‟t happened yet). 

The contract cannot start after a payment is due 

74 of 92

10 157 Total financed amount = [0] and ContractCategory = 

["instalment"] 

10 158 Number of Instalments = [0] and ContractCategory = 


10 160 Periodicity of Payment is empty and ContractCategory = 


10 163 

Monthly Instalment Amount = [0] and ContractCategory = 

["instalment"] and Contract phase = ["LV", "TM", "TA"] 

10 166 Amount of Next Expiring Instalment > [0] and 

ContractCategory = ["instalment"]) and Contract phase = 

["TM", "TA"] 

10 168 

10 169 

Number of remaining Instalments = [0] and 

ContractCategory = ["instalment"] and Contract phase = 

["LV"]) and File accounting date < Contract planned end 

date 

Number of remaining Instalments > [0] and 

ContractCategory = ["instalment"] and Contract phase = 

["TM", "TA"] 

10 171 Remaining Amount = [0] and ContractCategory = 

["instalment"]) and Contract phase = ["LV"] and File 

accounting date < Contract planned end date 

10 172 Remaining Amount > [0] and ContractCategory = 

["instalment"] and Contract phase = ["TM", "TA"] 

10 173 ContractCategory = ["instalment"] and (((Number of 

remaining Instalments >[0]) and (Remaining Amount = 

[0])) or ((Number of remaining Instalments = [0]) and 

(Remaining Amount > [0]))) 

10 175 Number of Overdue and not Paid Instalments > [0] and 

Contract phase = ["RQ", "RN", "RF"] 

10 176 

Number of Overdue and not Paid Instalments > [0] and 

Contract phase = ["LV", "TM", "TA"] and Number of 

Overdue and not Paid Instalments > [Total Number of 

Instalments - Number of remaining Instalments] 

10 179 Overdue and not Paid Amount > [0] and Contract phase = 

["RQ", "RN", "RF"] 

10 182 

ContractCategory = ["instalment", "card"] and Contract 

type ["CG"] and (((Number of Overdue and not Paid 

Instalments > [0]) and (Overdue and not Paid Amount = 

[0])) or ((Overdue and not Paid Amount > [0]) and 

(Number of Overdue and not Paid Instalments = [0]))) 

10 184 Credit limit = [0] and ContractCategory = ["card"] 

10 196 Contract type = ["CG", "CR"] and Flag Card used in the 

month = [0] and Number of times card has been used in 

the month > [0] 

10 197 Date of law suit is not empty and Date of law suit > File 

accounting date 

10 198 Date of law suit is not empty and Date of law suit < 

Contract starting date 

10 199 Date of law suit is not empty and Date of law suit < 

Contract actual end date 

Instalment contracts must have a total financed 

amount >0, or they would not be reported 

Instalment contracts by definition have instalments, 

therefore the number of instalments cannot be 0 

Please note that this is the average amount that 

would be paid on an instalment if the repayment 

plan were monthly. Therefore for an Instalment 

contract (that by definition has instalments) this 

amount can never be empty or zero as long as the 

contract is living. 

If there are no more instalments on an instalment 

contract, it means the contract is closed, since there 

is nothing left to pay. Therefore you cannot have 0 

remaining instalments on an instalment contract 

where the planned end date is in the future, and the 

phase is still living. 

When providing links between two Subjects (i.e. 

Owner – Company links), if one of the Subjects 

being linked has errors that prevent it from being 

correctly loaded, naturally the link cannot be loaded 

either since it is pointing to a Subject that is not in 

the database. The way to fix this is to correct the 

Subject data (in the next contribution or with CIB 

support), and re-submit the link with the next 

monthly contribution. 

If there are no more instalments remaining to be 

paid, the amount remaining to be paid must also be 

0. 

Total instalments are made up of Past instalments 

that have been paid, past instalments that have not 

been paid and are overdue, and future instalments 

that are yet to be paid. Therefore If a contract that 

is living or closed has, lets say, 10 total 

instalments, and there are 5 remaining instalments, 

in the worst case scenario there can be only 5 

overdue and not paid instalments, since overdue 

and not paid instalments + remaining instalments 

cannot possibly be more than total instalments. 

If there are no Overdue and not Paid Instalments, it 

follows that the total amount of Overdue and Not 

Paid Instalments must be 0 and vice versa. 

75 of 92

10 200 Date of classification is not empty and Date of classification 

> File accounting date 

10 201 Contract status = ["S", "D", "B", "W"] and Date of 

classification is empty 

10 251 FI CODE OF RECORD IS DIFFERENT FROM THE FI CODE 

THAT SENT CONTRIBUTION 

10 254 FI SUBJECT CODE IS EMPTY 

10 256 NID AVAILABILITY FLAG IS NOT IN THE DOMAIN 

10 258 NAME FIELD IS EMPTY AND THE SUBJECT IS INDIVIDUAL 

10 259 FATHER'S NAME FIELD IS EMPTY AND THE SUBJECT IS 

INDIVIDUAL 

10 261 TRADE NAME NOT FILLED FOR PROPRIETORSHIP 

10 264 TRADE NAME NOT FILLED FOR COMPANY 

10 267 MOTHER‟S NAME NOT FILLED FOR INDIVIDUAL 

10 273 OWNER'S MOTHER'S NAME NOT FILLED FOR 

PROPRIETORSHIP 

10 274 OWNER'S FATHER'S NAME NOT FILLED FOR 

PROPRIETORSHIP 

10 276 OWNER'S NAME NOT FILLED FOR PROPRIETORSHIP 

10 279 GENDER IS NOT IN THE DOMAIN 

10 283 DATE OF BIRTH FORMAT IS NOT CORRECT 

10 284 CODE OF SECTOR TYPE IS NOT IN THE DOMAIN 

10 285 CODE OF SECTOR CODE IS NOT IN THE DOMAIN 

10 286 PLACE OF BIRTH NOT FILLED FOR INDIVIDUAL 

10 287 PLACE OF BIRTH NOT FILLED FOR PROPRIETORSHIP 

10 288 POSTAL CODE FORMAT IS NOT NUMERIC 

10 289 RISK GRADING HAS AN INVALID FORMAT 

10 290 Y SCORE HAS AN INVALID FORMAT 

10 291 Z SCORE HAS AN INVALID FORMAT 

10 297 FI Subject Code of Company is empty (CTL) 

10 298 Owner's role in Company is not in domain or it is empty 

(CTL) 

10 299 FI Subject Code of Owner is empty (CTL) 

10 300 

SUBJECT HAS NOT LINKS WITH ANY INFORMATION 

10 304 Subject Role is not C or G (CTL) 

10 324 CODE OF LEGAL FORM IS NOT IN THE DOMAIN 

10 325 ID FIELD: CODE OF ID ISSUE COUNTRY IS NOT IN THE 

DOMAIN 

10 326 MAIN ADDRESS FIELD: CODE OF COUNTRY IS NOT IN THE 

DOMAIN 

10 327 ADDITIONAL ADDRESS FIELD: CODE OF COUNTRY IS NOT 

IN THE DOMAIN 

10 328 CODE OF COUNTRY OF BIRTH IS NOT IN THE DOMAIN 

10 337 Periodicity of Payment is empty and ContractCategory = 

["card"] and Contract Type ["RV"] 

10 343 ID FIELD: ID ISSUE DATE FORMAT IS NOT CORRECT 

10 344 

Contract refers to not existing subject 

Subjects can be contributed if they have a request, 

a financing, score information, or links to another 

Subject (Subject-Subject) links. If none of this 

information is present, the Subject will go in error. 

These are contracts that refer to a Subject that was 

not sent in the contribution of Subjects (or is in 

KO), and therefore raise an error. 

76 of 92

10 345 

Contract refers to subject in anomalies 

10 348 Contract Reorganized: checks between input and DB are 

failed 

10 349 Contract Reorganized: contract phase is not living 

10 350 Contract not Reorganized and not Credit Transeferred: 

checks on phase between input and DB are failed 

10 351 Contract not Reorganized and not Credit Transeferred: 

checks on contract type between input and DB are failed 

10 352 Contract not Reorganized and not Credit Transeferred: input 

contract has different applicant of DB contract 

10 353 A different subject (with different CB Subject Code) sent by 

the same Financial Institute with the same FI Subject Code 

exists in DB 

10 354 NID FIELD IS EMPTY 

10 355 NID FORMAT IS NOT CORRECT 

10 356 SECTOR CODE IS MANDATORY IF SECTOR TYPE IS 

PRESENT 

10 357 SECTOR TYPE IS MANDATORY IF SECTOR CODE IS 

PRESENT 

10 358 LINK OWNER-COMPANY: LINK PRESENT WITH DIFFERENT 

ROLE 

10 360 Link Subject-Contract: Applicant not existing 

10 361 Link Subject-Contract: subject linked (Guarantor or 

Coapplicant) not existing 

10 362 

Link with Subject Information: the subject not existing 

10 363 Type of Instalment is empty and Contract type = ["CR"] 

10 368 Link refers to subject in anomalies 

10 369 

LINK OWNER-COMPANY: SUBJECT NOT EXISTING 

10 370 

Contract starting date > Last payment date 

10 378 DATE OF BIRTH IS NOT CORRECT 

10 380 LINK SUBJECT-CONTRACT: LINK PRESENT WITH 

DIFFERENT ROLE 

5.5 BATCH EXAMPLE FILES 

Our system cross-checks information between 

Contracts and Subjects. If a Subject is contributed 

incorrectly, unless the error is completely blocking, 

their information is put in a special table of 

“anomalies”. This means that it is not visible by 

users, but the System knows the Subject is there. If 

the errors on the Subject are corrected, the Subject 

data is then loaded in the regular tables and visible 

by users. While the Subject is in anomalies, any 

Contracts that refer to such Subject are also placed 

in the anomalies table. Once the information on the 

Subject are corrected, these Contracts are 

automatically recovered and visible as well (unless 

further Contract errors are found). Therefore, the 

way to solve this problem is actually to fix the 

Subject data through the next contribution or with 

CIB support. 

This error goes hand in hand with error number 10- 

345. Just like we could not load the contract 

because the Subject was anomalous, also Subject 

Information (i.e. Yscore, Zscore, and Risk Grading) 

could not be loaded because the Subject was 

anomalous. Again, the way to solve this problem is 

actually to fix the Subject data through the next 

contribution or with CIB support. 

This occurs because in all these cases either the 

Owner or the Company were anomalous. Once the 

error that was causing them to be anomalous is 

fixed, the current error will be automatically fixed. 

The contract cannot start after the last payment is 

due 

As a separate file, we provide examples of contribution of subjects and contracts files. These files 

should be opened with an editor such as Notepad++ or Ultraedit to preserve the structure of the 

file as a single line. 

77 of 92

ABCCNF.txt 

ABCSJF.txt 

Here you can find a description of what those files contain: 

5.5.1 BATCH EXAMPLE FILES - Structure 

Files have the following structure: 

Subjects file: 

- Individual “1” 

- Company “1” 

- Individual “2” 

- Proprietorship “1” 

- Link subject-subject between Company “1” and Individual “2” 

Contracts file: 

- Non instalment Contract 1 for Individual “1” 

- Instalment Contract 2 for Company “1” 

- Subject information for Proprietorship “1” 

- Link of type Guarantor between Individual “2” and contract “1” (non instalment) 

5.5.2 BATCH EXAMPLE FILES - Data 

And Contain the following data: 

Subjects file: 

Individual 1: 

78 of 92

Company 1: 

Individual 2: 

79 of 92

Proprietorship 1: 

80 of 92

Contracts file: 

Non instalment Contract 1 for Individual “1” 

81 of 92

Instalment Contract 2 for Company “1” 

82 of 92

Subject information for Proprietorship “1” 

83 of 92

Link of type Guarantor between Individual “2” and contract “1” (non instalment) 

6 SPECIAL CASES AND EXCEPTIONS 

By the time you reach this section, you should have a clear understanding of the Batch process in 

general. There are, however, a series of “exceptions” and “special circumstances”. This 

paragraph aims at describing the correct way to contribute such special cases via batch. 

6.1 Changes to Subjects linked to a Contract 

If during the life of a Contract, the set of Subjects related to such contract changes, the following 

actions can be taknen: 

If the Borrower on a specific Contract changes: you must contact CIB directly at the contacts 

provided in section 2.1 with proof of the new Borrower. 

If a Co-Borrower on a specific Contract needs to be removed: you must contact CIB directly at 

the contacts provided in section 2.1 with proof of the existing Co-Borrowers on the account. 

If a Guarantor on a specific Contract needs to be removed: you must contact CIB directly at the 

contacts provided in section 2.1 with proof of the existing Guarantors on the account. 

If a Co-borrower on a specific Contract must be changed to Guarantor or vice versa: you must 

contact CIB directly at the contacts provided in section 2.1 with proof of the existing Co- 

Borrowers and or Guarantors on the account. 

Only in the case of ADDITION of a Co-Borrower or of a Guarantor, you can simply send the new 

Subject with the specific role on a specific Contract and it will be added to the list of related 

Subjects to that Contract automatically. 

6.2 Renounced/Refused credit applications 

Information relating to a credit line must be reported to CIB for its entire duration. Therefore, if 

the credit line is not granted or is abandoned by the borrower, this must be reported to the 

System. This will be done only once together with the regular contribution for the month in which 

it was Renounced by the Client or Refused by the FI. (See Paragraph 4.4). 

6.3 SPECIAL CASES FOR INSTALMENT CONTRACTS 

6.3.1 Contract with split and/or postponed drawdown 

In the case where the capital borrowed with an instalment credit is not drawn down at the 

moment in which the credit line is granted but afterwards, the credit line must be reported as 

Living with the date of the first capital drawdown and not before (for example not with the date 

that the credit line was granted). 

The borrowed capital which must be reported is that which is actually drawn down even if it is 

different from the amount reported in the contract signed by the customer. In the case where 

the drawdown is split, the amount reported in the monthly contribution is that which has been 

drawn down up to that reference month, i.e. the sum of the individual amounts already drawn 

down. 

84 of 92

Please note: this does not apply to non-instalment loans or credit cards. In such cases, the 

contract is reported as Living from the moment the credit is granted, and the Total financed 

amount is the total amount of the credit, not the drawn down or utilized amount. 

6.3.2 Contract with the first installment due date after the credit drawdown 

When an Instalment Contract is granted at time t(0), but the data client is asked to pay the first 

instalment after this time, at time t(1) (which could also be many months after the credit line 

drawdown), the Contract should be added and contributed as Living at time t(0) and the 

Expiration Date of Next Instalment as time t(1). The credit report will be updated monthly with 

the same information until time t(1) is reached, when the amortization plan comes into effect. 

Please note: this does not apply to non-instalment loans or credit cards. In such cases, the 

contract is reported as Living from the moment the credit is granted, and the Total financed 

amount is the total amount of the credit, not the drawn down or utilized amount. 

6.3.3 Mortgages splitting 

The splitting of a mortgage occurs when a property, bought in its entirety by a client taking out a 

mortgage, becomes subdivided into parts and re-sold to more purchasers, each purchaser 

assuming a share of the mortgage which corresponds to the value of the assets purchased. It 

generally occurs when a construction company or cooperative borrows money for the 

construction of the property and then sells the single apartments, passing on the respective 

share of the mortgage to each purchaser. 

Generally, the mortgage that the construction company takes out has a delayed first installment 

due date with respect to the drawdown of the capital and may also have a split drawdown. For 

these cases the information is specified in the previous sections. 

Often the original mortgage is reduced gradually as the individual parts are sold, which generates 

new mortgages at the same time. 

This process is managed as follows: 

a) The original mortgage must remain active until the splitting process is complete. The Monthly 

Instalment Amount, Remaining Amount, and Overdue and not Paid Amount are reported as 

standard. 

b) At the moment in which an apartment is sold, a new mortgage is generated, which absorbs a 

proportion of the Total financed amount of the original mortgage and must be reported as a new 

contract. At the same time, the original mortgage must be reported and updated with a Total 

financed amount equal to [Total financed amount of the previous month – Total financed amount 

absorbed by the new mortgage] and with a Monthly Instalment Amount recalculated on the 

Remaining Amount. This process is repeated until a purchaser buys the final apartment and 

therefore the last new mortgage absorbs the remaining part of the original one. 

c) The original mortgage will close in advance, probably before an amortization plan is started. 

6.3.4 Irregular payment behaviour 

Instalment contracts do not always follow a schedules with fix amounts of repayment at regular 

intervals. Whenever either the schedule of repayment or the amounts themselves follow an 

“irregular” pattern, we treat them as irregular payment behaviours. 

In such cases, our approach is to “regularize it” as much as possible through the use of specific 

fields, namely „Monthly Instalment Amount‟ , „Amount of Next Expiring Instalment‟ , and 

„Expiration Date of Next Instalment‟ . 

85 of 92

Specifically, the „Monthly Instalment Amount‟ of an instalment loans with irregular payments is 

simply calculated by taking the total amount financed and this figure is divided by the total 

number of months of the loan. 

For example, assume we have an instalment loan granted in January 1 st 2008, where the final 

expiration is in December 31 st 2008, and the total amount of the loan is 120,000,000 taka. 

Regardless of what the individual payments are, and when they occur, the „Monthly Instalment 

Amount‟ will be 120,000,000 / 12 = 10,000,000 taka. This is the same behaviour applied to any 

instalment contract that is not repaid on a monthly basis. 

Once the Monthly Instalment Amount is determined, you need to remember to set “Periodicity” to 

the correct one (using „I‟ if it is irregular). 

Next you need to correctly fill the „Amount of Next Expiring Instalment‟ and the „Expiration Date 

of Next Instalment‟. The correct way to fill these out depends on the specific situation: 

If the actual amount and Expiration Date of Next Instalment of a future irregular payment 

is known more than one month in advance, both should be reported (see Example 1). 

In case the irregular payment is not known in advance there are two different scenarios. 

o The first is if the customer still pays a regular monthly payment and occasionally 

they pay irregular payment. In this case both fields „Amount of Next Expiring 

Instalment‟ and 'Expiration Date of Next Instalment' should be blank until 

the irregular payment is known (see Example 2). 

o In the second case, i.e. the customer does not pay any regular payments between 

irregular payments, the field 'Amount of Next Expiring Instalment' should be set to 

0 (zero) and the field 'Expiration Date of Next Instalment' should be set to a valid 

date (next month). If the date is validated, any amount that is reported as zero 

means that there was 'no payment' for that date (see Example 3). 

Example 1: irregular payment known in advance 

Accounting 

Date 

Monthly 

Instalment 

Amount 

Amount of Next 

Expiring 

Instalment 

Expiration Date 

of Next 

Instalment 

31/01/2008 500,000 1,000,000 30/04/2008 

29/02/2008 500,000 1,000,000 30/04/2008 

31/03/2008 500,000 1,000,000 30/04/2008 

30/04/2008 500,000 2,000,000 30/10/2008 

… … … … 

Example 2: irregular payment not known in advance; customer pays regular installments 

Accounting 

Date 

Monthly 

Instalment 

Amount 

31/01/2008 500,000 

29/02/2008 500,000 


Expiring 

Instalment 


of Next 

Instalment 

31/03/2008 500,000 2,000,000 30/04/2008 

30/04/2008 500,000 

… … … 

Example 3: irregular payment not known in advance; customer does not pay any regular 

installments 

Accounting 

Date 

Monthly 

Instalment 

Amount 


Expiring 

Instalment 

86 of 92 


of Next 

Instalment 

31/01/2008 500,000 0 29/02/2008 

29/02/2008 500,000 0 31/03/2008

31/03/2008 500,000 1,000,000 30/04/2008 

30/04/2008 500,000 0 31/05/2008 

… … … 

Please notice that in our examples the Instalment Amount was always set to 500,000. This doen‟t 

mean that each month 500,000 were due by the Borrower. Quite the opposite, as the actual 

amount paid can be seen in the Amount of Next Expiring Instalment column. Rather, the 500,000 

taka is the calculated Monthly Installment Amount taken by dividing the total Financed Amount 

divided by the months of duration of the loan. 

87 of 92

6.4 CREDIT REORGANIZATION (also known as RESTRUCTURING) 

There are cases in which an existing credit is “reorganized” or “restructured”. This can occur for a 

number of reasons, usually tied to an attempt to change the terms of payment in order to ensure 

that payment occurs. Please note that this paragraph is not going to go into the policy 

prescriptions of when to restructure or how to actually perform the restructuring within your 

institute. These indications are provided by existing Bangladesh Bank documents. 

Rather, the paragraph will list the technical aspects of communicating a restructuring that 

occured to the online system. 

In other words, we are going to describe three different ways in which the system can be notified 

when a credit reorganization has occured. You should choose the specific function that best 

reflects the existing practices within your institution, and follows Bangladesh Bank policy 

prescriptions. 

We will now turn to the ways in which a reorganization can be submitted to the Bureau, and use 

concrete examples for ease of understanding. 

Let‟s say, as an example, that Bank “1” has an existing Subject “Mr. A” with an ongoing 

Installment contract “I” with a monthly schedule of repayments. 

Mr.A has been a good payer in the past, but recently he has become erratic in his payments. 

After a talk and a review with Mr. A, Bank 1 becomes persuaded that Mr. A will not be able to 

meet his upcoming commitments on the contract, but is solvent in the long term. Bank 1 

therefore decides to propose a credit reorganization to Mr. A that lowers his monthly payments, 

but increases the length of the contract. 

At this point, there are three possible ways to record this arrangement: 

6.4.1 Credit is reorganized while maintaining the same FI Contract code 

The old Contract is closed, a new one is opened, but the FI contract code of the new one remains 

the same. Also, the new contract is labeled as a reorganized contract. 

If we adopt this process, it is possible to change not only the payment plan (periodicity, amount, 

closing date, etc), but even the type of loan. So for example this can be used if a client cannot 

88 of 92

epay a non instalment loan that is due, and the bank restructures the credit as an installment 

repayment plan. 

In order for the system to register the reorganization in this function, during that particular batch 

contribution for that month, you will need follow the structure indicated in section 5.2.5 but 

paying attention to the following fields: 

- F.I.Contract Code = remains the same as the contract that we are closing 

- Contract Phase= must be set to LV (Living) 

- Contract Type = can be same as the contract that we are now closing, or a different 

one 

- Flag Reorganized Credit = “1” 

The system will interpret this information as follows. The old contract will be closed in advance. A 

new contract will be opened with the same FI code and with a note that indicates it is a 

reorganized credit. 

Beginning with the next month, the contribution will be back to “normal” 

- F.I.Contract Code = remains the same (in Body for Record Type: General information 

for all types of Financing, positions from 25 to 40, of the Contract Data File) 

- Contract Phase= must be set to LV (Living) unless the reorganized contract was also 

closed (in Body for Record Type: General information for all types of Financing, 

positions from 43 to 44, of the Contract Data File) 

- Contract Type = must be the same that was sent the previous month (in Body for 

Record Type: General information for all types of Financing, positions from 41 to 42, 

of the Contract Data File) 

- Code Reorganized Credit = “0” (note that it is back at 0!!!) (in Body for Record Type: 

General information for all types of Financing, spaces from 94 to 94, of the Contract 

Data File) 

89 of 92

6.4.2 Credit reorganization without creating a new contract 

The system also handles a different way to reorganize/restructure contracts. Note that this 

approach does not work if we want to change the Contract Type. This approach does not close 

the initial contract and open a separate one as reorganized credit, but rather modifies the 

existing contract and adds a note that the credit has been reorganized. 

In order for the system to register the reaorganization in this function, during that particular 

batch contribution for that month, you will need follow the structure indicated in section 5.2.5 but 

paying attention to the following fields: 

- F.I.Contract Code = remains unchanged (in Body for Record Type: General 

information for all types of Financing, positions from 25 to 40, of the Contract Data 

File) 

- Contract Phase= LV (Living) (in Body for Record Type: General information for all 

types of Financing, positions from 43 to 44, of the Contract Data File) 

90 of 92

- Contract Type = must be the same as the previous contract (in Body for Record Type: 

General information for all types of Financing, positions from 41 to 42, of the 

Contract Data File) 

- Code Reorganized Credit = “2” (in Body for Record Type: General information for all 

types of Financing, spaces from 94 to 94, of the Contract Data File) 

This needs to be performed only the specific month of the restructuring. Beginning with the next 

month, the reporting of the contract will become regular again and therefore the same fields will 

have the following values: 

- Contract Phase= LV (Living) (in Body for Record Type: General information for all 

types of Financing, positions from 43 to 44, of the Contract Data File) 

- Contract Type (Instalment, Non-Instalment, Cards) = must be same as previous 

month (in Body for Record Type: General information for all types of Financing, 

positions from 41 to 42, of the Contract Data File) 

- Code Reorganized Credit = “0” (in Body for Record Type: General information for all 

types of Financing, spaces from 94 to 94, of the Contract Data File) 

6.4.3 Credit restructuring through the direct opening of a new credit line 

Finally, credit reorganization can be simply done by closing a non-performing Contract (sending it 

in Contract Phase TA) and open a different contract (sending it in Contract Phase LV). 

In this case, however, the system will not track any relationship between the two contracts. 

91 of 92

6.5 RE-OPENING OF TERMINATED/TERMINATED IN ADVANCE LOANS 

In case the phase of a contract was incorrectly contributed as terminated/terminated in advance 

(TM/TA), in order to correct this and restore the original status, the FI has simply to send again 

the contract with phase living (LV) through the monthly batch contribution. This will automatically 

solve the problem. 

92 of 92

Batch User Guide produced by CRIF - Janata Bank

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?