Requirements Definition Document

Amendment sheet

Name Process Role Date

Prepared By Venkatesan N Saravanan 04 Jan 2017
Reviewed By
Approved By
 Revision History

Revision Number Date Rational For Change & Ref. Of Change Sections

Reference Documents

Document Name Version Document Name Version

AECB_Credit Data
Submission Requirements
2.3
and Data Dictionary_3
4_WO.pdf
Requirements Definition Acceptance Statement

Signed By

Client Side - <Name of the Person, Designation>

Raqmiyat - <Name of the Person, Designation>

Sign-Off date

Deliverable: Requirements Definition Document

This Requirements Definition (RD) serves as the foundation for all efforts on this project and
takes precedence over all documentation that was used to develop the RD. This document
defines the requirements/modifications to the release required to accommodate the <Specify the
Raqmiyat Solution>. Before continuing with the project, it is essential that all parties agree that
the information contained in this document is accurate and complete. To acknowledge <Client
Name> acceptance of the deliverable defined above, please have an authorized representative
sign and date in the space provided below. Any future changes made to the requirements will go
through a Change Control process.
 TABLE OF CONTENTS
1 EXECUTIVE SUMMARY....................................................................................................................5
1.1 INTRODUCTION...................................................................................................................................5
1.2 SUPPORTING DOCUMENTATION.........................................................................................................5
1.3 SCOPE..............................................................................................................................................5
1.4 ASSUMPTIONS, CONSTRAINTS AND DEPENDENCIES........................................................................6
2 BACKGROUND AND BUSINESS REQUIREMENTS - SUMMARY...........................................7
ARCHITECTURE DIAGRAM..............................................................................................................................7
2.1 LINES OF BUSINESS...........................................................................................................................7
2.2 SUMMARY OF EXISTING AND PROPOSED SYSTEM CONFIGURATION..............................................7
2.3 PROCESSING LOCATION AND INSTALLATION SITES..........................................................................8
2.4 BUSINESS REQUIREMENTS OVERVIEW & SUMMARY.......................................................................9
2.5 SUMMARY OF PROPOSED SOLUTION................................................................................................9
2.6 BENEFITS............................................................................................................................................9
3 FUNCTIONAL REQUIREMENTS...................................................................................................10
3.1 SUMMARY.........................................................................................................................................10
3.2 DETAIL..............................................................................................................................................10
3.2.1 DataLoader Service............................................................................................................10
3.2.2 Data Mapping.......................................................................................................................19
3.2.3 User Maintenance...............................................................................................................27
3.2.4 Master Maintenance...........................................................................................................30
3.2.5 Home Dashboards..............................................................................................................32
3.2.6 Initial Data Submission.......................................................................................................32
3.2.7 Periodic Subject Data Submission...................................................................................33
3.2.8 Data Updation......................................................................................................................39
3.2.9 Data Submission for Portfolio Transfer............................................................................40
3.2.10 CB Response Processing.............................................................................................41
3.2.11 Data Correction Rectification........................................................................................41
3.2.12 Encryption Service..........................................................................................................42
3.2.13 Decryption Service.........................................................................................................42
3.2.14 Configuration Maintenance...........................................................................................43
3.2.15 Audit..................................................................................................................................43
3.2.16 Standard Reports............................................................................................................43
4 COMPONENT REQUIREMENTS...................................................................................................47
5 NON FUNCTIONAL REQUIREMENTS.........................................................................................48
6 INTERFACE REQUIREMENTS.......................................................................................................49
6.1 INTERNAL INTERFACE......................................................................................................................49
6.2 EXTERNAL INTERFACE.....................................................................................................................49
7 WORK FLOW.....................................................................................................................................50
APPENDIX A SAMPLE FILES..............................................................................................................52
APPENDIX B SAMPLE SCREENS......................................................................................................53
1 EXECUTIVE SUMMARY

1.1 INTRODUCTION

This Requirement Definition document defines the requirements for Credit Reporting system as it
pertains to Raqmiyat. The document includes the items identified as in the scope of Credit
Reporting system.
This document describes the various operations and configuration setup functional requirements
of the Raqmiyat system necessary to achieve the business requirements of Credit
ReportingSystem.

1.2 SUPPORTING DOCUMENTATION

Al Etihad Credit Bureau - Credit Data Submission Requirements and Data Dictionary v2.3.pdf

1.3 SCOPE

Proposed system enables the Credit Provider to submit its data to the Credit Bureau. The Credit
Bureau then passes the data through the data validation processes. The valid data is loaded into
the Credit Bureau Database. The invalid data is not loaded into the Credit Bureau Database and
is used to create an Error File which is sent back to the Credit Providers detailing, record by
record, the errors. The Credit Provider then corrects these records and resubmits them (in
Correction Mode: C) to the Credit Bureau.

Following would be part of the scope

Credit Data Submission

Maintenance of the credit Bureau data
Ability to Correct Data
Identification of Contracts
Identification of Subjects
Identification of links
Links of Individuals to companies
Maintain the payment behavior on contracts
Data will be localized and securely supplied
Data Validation
Error reports
Name of Individuals in English and Arabic
Company Name in English and Arabic
1.4 ASSUMPTIONS, CONSTRAINTS AND DEPENDENCIES

External Factors:

It is assumed that the subject and contract data for credit bureau would be extracted from
different systems in the bank and would be provided to the system in the form of csv in a shared
location.
2 BACKGROUND AND BUSINESS REQUIREMENTS -
SUMMARY

ARCHITECTURE DIAGRAM

Describe here the background of the customer with the following information

2.1 LINES OF BUSINESS

Currently unavailable

2.2 SUMMARY OF EXISTING AND PROPOSED SYSTEM CONFIGURATION

Sl.No Environment Existing Proposed/New Remarks

1 Application Software System N/A
2 Hardware for Test N/A Windows Server
environment 2008 R2, 2 GB
RAM for web
server and
Windows Server
2008 R2, 4 GB
RAM for SQL
Server.
3 Hardware for Production N/A Windows Server
environment 2008 R2, 8 GB
RAM for web
server and
Windows Server
2008 R2, 16 GB
RAM for SQL
Server.
4 Software N/A IIS 7/7.5 Web
Server/ SQL
Server 2008
R2, .NET
Framework 3.5
SP1,
5 Scanners and their make N/A N/A
6 No.of Data entry PCs N/A N/A
7 No.of custom reports N/A Approx. 10 mbps This would
depend on the
peak load.
8 Network connectivity N/A Unknown
9 Third party software N/A N/A
10 Distributed processing N/A N/A
11 Volume of transactions N/A Unknown

Note: If there are any unknown elements in the above table during RD discussion with the
customer, Project manager shall ensure that it is updated before the development is completed.

2.3 PROCESSING LOCATION AND INSTALLATION SITES

The software will be deployed as web application. The following are the details of various
modules and its location.

S.No Module Location Physical location Remarks

1. User Web server
Maintenance
2. Core Web server
3. Dataloader Web server
4. Reports Web server
5 Audit Web server
6 Masters Web server
7 Export Service Web server
8 Import Service Web server
9 Encrypt Service Web server
10 Decrypt Service Web server
2.4 BUSINESS REQUIREMENTS OVERVIEW & SUMMARY

System would enable the Credit Provider to submit its credit releated data to the Credit Bureau.
The Credit Bureau then passes the data through the data validation processes. The valid data is
loaded into the Credit Bureau Database. The invalid data is not loaded into the Credit Bureau
Database and is used to create an Error File which is sent back to the Credit Providers detailing,
record by record, the errors. The Credit Provider then corrects these records and resubmits them
(in Correction Mode: C) to the Credit Bureau.

2.5 SUMMARY OF PROPOSED SOLUTION

Ability to validate the Subject data.

Ability to send Subject data periodically without manual intervention to Credit Bureau.
Ability to validate the Contract data.
Ability to send Contract data periodically without manual intervention to Credit Bureau.
Ability to correct the data if an error file is received from CB after validation at CB.
Ability to send corrected Subject or contract data to CB.
Ability to send updates for Subject to CB.
Ability to send updates for Contracts to CB.
Abiliity to send Portfolio transfer data to CB.
Standard Reports are available. Detail of the reports would be provided in the Reports Section.

2.6 BENEFITS

The system automates the periodical submission of Subject and contract data to Credit Bureau.
Also in case of change in Subject or contract detail as well as any portfolio changes, ti sends data
to CB as required. So it removes any manual latency and the submission of data to CB is
seamless and elimates manual labor cost and manual error. It also provides automated
validations of the data based on the rule engine by which it provides accurate data and eliminates
any manual error in validations. It uses maker/checker concept there by implements four eyes
verification. It also provides various reports.
3 FUNCTIONAL REQUIREMENTS

3.1 SUMMARY

S.No Product Feature/Module Source of the

Requirement
1 CRS Dataloader service
2 CRS Data Mappings
3 CRS User Maintenance
4 CRS Master Maintenance
5 CRS Home Dashboards
6 CRS Initial Data Submission Section 5.1.1
7 CRS Periodic Subject and Section 5.1.1
Contract Data Submission
8 CRS Data Updation as required Section 5.1.2
9 CRS Data Submission for portfolio Section 5.1.4
transfer as required
10 CRS CB Response Processing Section 5.4.1
11 CRS Data Correction Rectification Section 5.5.1
12 CRS Encryption Service Section 5.1.1, 5.1.2
13 CRS Decryption Service Section 5.1.1, 5.1.2
14 CRS Configuration Maintenance
15 CRS Audit Report
16 CRS Standard Reports

3.2 DETAIL

3.2.1 DataLoader Service

3.2.1.1Requirement Summary:

The subject and contract data has to be periodically downloaded from source (Core banking)

Requirement Detail:

All subject and contract data would be available in core banking which is the source for CRS. This
data has to be available in shared drive in csv format. This would be uploaded to CRS DB using
this DataLoader service.

3.2.1.1.1 Implementation:

Data from source of CRS (Core Banking) would be available in shared drive in csv format. This
would be loaded to CRS DB using VLink. This downloading of data would be done periodically in
set intervals.

The data for Subject (Individual/Company) from source has to come in csv format. Detail of field
as below
 Field DataType Field Validation M/O/C
Provider Code Varchar(5) Field length - VARIABLE M
minimum 1 character
maximum 5 characters
Alphanumeric
BatchId Varchar(16) Field length - VARIABLE M
minimum 1 character,
maximum 16 characters
Alphanumeric
No special characters
allowed except
Minus (-)
ExtractDateTime Datetime 8 Field length FIXED M
char date 16 characters
(ddmmyyyy)
Individual
Record Id Positive Integer, M
minimum 1 digit
maximum 12 digits
Provider Subject Varchar(16) Field length - VARIABLE M
Number minimum 1 character,
maximum 16 characters Alphanumeric
No special characters allowed except
underscore ( _ ) and Minus (-)
Date of Last Update Datetime 8 Field length FIXED, 16 M
char date Character (ddmmccyyhh:mm:ss)
(ddmmyyyy)
First Name in English Varchar (50) Field length - VARIABLE C
minimum 1 character
maximum 50 characters
digits and special
characters other than a
minus (-) are not allowed
Last Name in English Varchar (50) Field length - VARIABLE C
minimum 1 character maximum 50 characters
Full Name in English Varchar (50) Field length - VARIABLE C
minimum 1 character,
maximum 120 characters
digits and special
characters other than a minus (-) are not
allowed
First Name in Arabic nVarchar (50) Field length - VARIABLE C
minimum 1 character
maximum 50 characters
digits and special
characters other than a
minus (-) are not allowed
Last Name in Arabic nVarchar (50) Field length - VARIABLE O
minimum 1 character
maximum 50 characters
digits and special
characters other than a
minus (-) are not allowed
Full Name in Arabic nVarchar (50) Field length - VARIABLE C
minimum 1 character
maximum 120 characters
digits and special
characters other than a
minus (-) are not allowed
Date of Birth Datetime Field length FIXED, O
ddmmyyyy 8 character (ddmmccyy)
Gender Char(1) Field length FIXED M
1 character
Source Gender Type
Table
Title (Mr/Ms/Mrs) Varchar (20) Field length - VARIABLE O
minimum 1
Character
maximum 20 characters
digits are not allowed
Source Title Type Table
Resident Flag Char (1) Field Length FIXED, O
1 character
Source Yes No Type Table
Nationality Char (2) Field length FIXED, C
2 characters
Source Country Codes
Table
Passport # Varchar (20) Field length - VARIABLE O
minimum 1 character,
maximum 20 characters
PassportExpiryDate Datetime 8 Field length FIXED, O
char date 8 character (ddmmccyy)
(ddmmyyyy)
DrivingLicenseNumber Varchar (20) Field length - VARIABLE C
minimum 1 character,
maximum 20 characters
EmiratesID Varchar (20) Field length VARIABLE, C
minimum 15 character
(without separators),
maximum 18 characters
(with separators)
Allowed characters: Digits
and -(minus) symbol
Address Varchar (200) Field length - VARIABLE O
minimum 1 character,
Maximum 200 characters
Alphanumeric
Address in Arabic nVarchar nVarchar (200) O
(200)
Emirates Address Char (1) Field length - FIXED1 O
character
Source Emirate Type
Table
Plot Number Varchar(10) Field length - VARIABLE O
minimum 1 character,
maximum 10 characters
PoBox Varchar(10) Field length - VARIABLE O
 minimum 1 character,
maximum 10 characters
Contact Phone Varchar(20) Field length - VARIABLE O
Number minimum 1 character,
maximum 20 characters
Allowable characters:
digits plus(+) and spaces
Mobile Number Varchar(20) Field length - VARIABLE O
minimum 1 character
maximum 20 characters
Allowable characters:
digits plus(+) and spaces
Additional Mobile Varchar(20) Field length - VARIABLE O
minimum 1 character,
maximum 20 characters
Allowable characters:
digits plus(+) and spaces
Email Varchar(120) Field length - VARIABLE O
minimum 1 character,
maximum 120 characters
Employer Name Varchar(120) Field length - VARIABLE C
minimum 1 character,
maximum 120 characters
Alphanumeric
EmployeDate Datetime 8 Field length FIXED, O
char date 8 characters
(ddmmyyyy) (ddmmccyy)
Termination Date Date Field length FIXED, O
8 characters
(ddmmccyy)
Gross Annual Income Decimal(12,0) Positive Integer, O
minimum 1 digit,
maximum 12 digits
Employment Type Char (2) Field length FIXED, O
2 characters
Source Employment Type
Table
Other Income Source Char (2) Field length FIXED, C
2 characters
Source Income Source
Table
Other Income Amount Decimal(12,0) Positive or Zero Integer, O
minimum 1 digit,
maximum 12 digits
Company
RecordID Positive Integer, M
minimum 1 digit
maximum 12 digits
ProviderSubjectNo Varchar(16) Field length - VARIABLE M
minimum 1 character
maximum 16 characters
Alphanumeric,
No special characters
except underscore ( _ )
and Minus (-) are allowed
DateOfLastUpdate Datetime 8 Field length FIXED, M
char date 16 characters
(ddmmyyyy (ddmmccyyhh:mm:ss)
Trade Name Varchar(120) Field length - VARIABLE C
minimum 1 character,
maximum 120 characters
Alphanumeric
Trade Name Arabic Varchar(120) Field length - VARIABLE C
minimum 1 character,
maximum 120 characters
Alphanumeric
Trade Registration Varchar(60) Field length - VARIABLE O
Place minimum 1 character,
maximum 60 characters
Alphanumeric
Trade License Varchar(25) Field length - VARIABLE M
Number minimum 1 character,
maximum 25 characters
Alphanumeric
DateOfEstablishme Datetime 8 Field length FIXED, O
nt char date 8 characters
(ddmmyyyy (ddmmccyy)
Emirates Address Char (1) Field length - FIXED1 O
character
Source Emirate Type
Table
Plot Number Varchar(10) Field length - VARIABLE O
minimum 1 character,
maximum 10 characters
PoBox Varchar(10) Field length - VARIABLE O
minimum 1 character,
maximum 10 characters
Contact Phone Varchar(20) Field length - VARIABLE O
Number minimum 1 character,
maximum 20 characters
Allowable characters:
digits plus(+) and spaces
Mobile Number Varchar(20) Field length - VARIABLE O
minimum 1 character
maximum 20 characters
Allowable characters:
digits plus(+) and spaces
Additional Mobile Varchar(20) Field length - VARIABLE O
minimum 1 character,
maximum 20 characters
Allowable characters:
digits plus(+) and spaces
Email Varchar(120) Field length - VARIABLE O
minimum 1 character,
maximum 120 characters
LINK
RecordId int Positive Integer, M
minimum 1 digit
maximum 12 digits
ProviderPrimarySu Varchar(16) Field length - VARIABLE M
bjectNo minimum 1 character,
maximum 16 characters
Alphanumeric
No special characters
except underscore ( _ )
and Minus (-) are allowed
ProviderSecondary Varchar(16) Field length - VARIABLE M
SubjectNo minimum 1 character,
maximum 16 characters
Role Char(2) Field length FIXED, M
2 characters
Source Subject Role Type
Table
TerminatedFlag Char(1) Field length FIXED, O
1 character
Source Yes No Type Table

The data for Contract from source has to come in csv format. Detail of field as below

Field DataType Field Validations

Provider Code Varchar(5) Field length VARIABLE minimum 1 M
character
maximum 5 characters Alphanumeric
BatchID Varchar(16) Field length - VARIABLE M
minimum 1 character,
maximum 16 characters
Alphanumeric
No special characters
allowed except
Minus (-)
Extract Date Time Datetime 8 Datetime 8 char date (ddmmyyyy) M
char date
(ddmmyyyy)
ModeType Char(1) Field length FIXED M
1 character
Source: Mode Type Table
ProviderContractNo Varchar(35) Field length - VARIABLE M
minimum 1 character,
maximum 35 characters
Alphanumeric, No special
characters except Minus (-)
are allowed
OriginalCurrency Char(3) Field length FIXED, O
3 characters
Source Currency Codes Table
ReferenceDate Char(6) Field length FIXED, 6 M
character (mmccyy)
ContractType Char(2) Field length FIXED, M
2 characters
Source: Contract Type Table
ActiveFlag Char(1) Field length FIXED, M
1 character
Source: Active Flag Type
OpenDate Datetime 8 Field length FIXED, 8 M
char date character (ddmmccyy)
(ddmmyyyy)
ClosedDate Datetime 8 Field length FIXED, 8 C
char date character (ddmmccyy)
(ddmmyyyy)
ContractStatus Char(1) Field length FIXED, M
1 character
Source Status Type Table
ContractStatusDate Datetime 8 Field length FIXED, N/A
char date 8 characters
(ddmmyyyy) (ddmmccyy)
Installment
TotalAmount Decimal(12,0) Positive Integer, M
minimum 1 digit,
maximum 12 digits
PaymentAmount Decimal(12,0) Positive Integer, M
minimum 1 digit,
maximum 12 digits
NoOfInstalments Numeric(3,0) Positive Integer, M
minimum 1 digit,
maximum 3 digits
NoOfRemainingIns Numeric(3,0) Positive or Zero Integer, M
talments minimum 1 digit,
maximum 3 digits
MethodOfPayment Char(3) Field length FIXED, O
3 characters
Source Method of Payment
Type
PaymentFrequency Char(1) Field length FIXED, M
1 character
Source PaymentFrequency
table
Default is M
Balance Decimal(12,0) Positive or Zero Integer, M
minimum 1 digit,
maximum 12 digits
OverdueAmount Decimal(12,0) Positive or Zero Integer, M
minimum 1 digit,
maximum 12 digits
Default is zero
DaysPaymentDelay int Field length FIXED, M
1 character,
Source DPD Type Table
Default is 0
IslamicContractFlag Char(1) Field length FIXED, O
1 character
Source Yes No Type Table
Default is based on banks
SecuredContractFlag Char(1) Field length FIXED, O
1 character
Source Yes No Type Table
NotInstalment
CreditLimit Positive or zero Integer, M
minimum 1 digit,
maximum 12 digits
Balance Decimal(12,0) Positive or zero Integer, M
minimum 1 digit,
maximum 12 digits
OverdueAmount Decimal(12,0) Positive or Zero Integer, O
minimum 1 digit,
maximum 12 digits
DaysPaymentDelay int Field length FIXED, O
1 character,
Source DPD Type Table
Default is 0
IslamicContractFlag Char(1) Field length FIXED, O
1 character
Source Yes No Type Table
Default is based on banks
principles
SecuredContractFlag Char(1) Field length FIXED, O
1 character
Source Yes No Type Table
CreditCard
MethodOfPayment Char(3) Field length FIXED, O
3 characters
Source Payment Type Table
Default value is CAS
PaymentFrequency Char(1) Field length FIXED, M
1 character
Source Payment Frequency
Type Table
Default is M
CreditLimit Decimal(12,0) Positive or zero Integer, M
minimum 1 digit,
maximum 12 digits
MinimumPayment Decimal(2,0) Positive or zero Integer, M
Percentage minimum 1,
maximum 2 digits
Balance Decimal(12,0) Positive or zero Integer, M
minimum 1 digit,
maximum 12 digits
OverdueAmount Decimal(12,0) Positive or zero Integer, M
minimum 1 digit,
maximum 12 digits
CardUsedFlag Char(1) Field length FIXED, M
1 character
Source Yes No Table
AmountSpentInMonth Decimal(12,0) Positive or zero Integer, O
minimum 1 digit,
maximum 12 digits
MinimumPayment Char(1) Field length FIXED, M
Flag 1 character
 Source Yes No Table
MinimumPayment Char(1) Field length FIXED, M
Flag 1 character
Source Yes No Table
DaysPaymentDelay int Field length FIXED, M
1 character,
Source DPD Type Table
Default is 0
IslamicContractFlag Char(1) Field length FIXED, O
1 character
Source Yes No Type Table
Default is based on banks
principles
SecuredContractFlag Char(1) Field length FIXED, O
1 character
Source Yes No Type Table
Services
BilledAmount Decimal(12,0) Positive or Zero Integer, M
minimum 1 digit,
maximum 12 digits
Balance Decimal(12,0) Positive or Zero Integer, M
minimum 1 digit,
maximum 12 digits
OverdueAmount Decimal(12,0) Positive or Zero Integer, M
minimum 1 digit,
maximum 12 digits
DaysPaymentDelay int Field length FIXED, M
1 character,
Source DPD (Services only)
Type Table
Default is 0
NoOfServices/Voice Positive or Zero Integer, C
minimum 1 digit,
maximum 4 digits
NoOfServices/Data Positive or Zero Integer, C
minimum 1 digit,
maximum 4 digits
NoOfServices/Other Decimal(4,0) Positive or Zero Integer, C
minimum 1 digit,
maximum 4 digits
CommunicationType Field length FIXED, C
characters 2
Source Communication Type
Table
HolderIsNotLiable Field length FIXED, O
1 character
Source Yes No Type Table
Link
RecordId int Positive Integer, M
minimum 1 digit
maximum 12 digits
ProviderContractNo Varchar(16) Field length - VARIABLE M
minimum 1 character,
maximum 16 characters
Alphanumeric,
 No special characters except
underscore ( _ ) and Minus
(-) are allowed
ProviderSubjectNo Varchar(16) Field length - VARIABLE M
minimum 1 character,
maximum 16 characters
Alphanumeric
No special characters except
underscore ( _ ) and Minus
(-) are allowed
Role Char(1) Field length FIXED, 1 character Refer to
Source Contract Role Type Contract
Role
Type
table for
valid
values

3.2.2 Data Mapping

3.2.2.1Requirement Summary:

The subject and contract data has to be mapped.

Requirement Detail:

After loading data from source of CRS to CRS DB, the subject and contract have to be mapped.

3.2.2.1.1 Implementation:

After loading data from source of CRS to CRS DB, the subject and contract have to be mapped..

The data for Subject (Individual/Company) from source has to come in csv format. Detail of field
as below

Field DataType&Size M/O/C

Provider Code Field length - VARIABLE M
minimum 1 character
maximum 5 characters
Alphanumeric
BatchId Field length - VARIABLE M
minimum 1 character,
maximum 16 characters
Alphanumeric
No special characters
allowed except
Minus (-)
ExtractDateTime Field length FIXED M
16 characters
Individual
Record Id Positive Integer, M
minimum 1 digit
maximum 12 digits
Provider Subject Number Field length - VARIABLE M
minimum 1 character,
maximum 16 characters Alphanumeric
No special characters allowed except underscore ( _ )
and Minus (-)
Date of Last Update Field length FIXED, 16 M
Character (ddmmccyyhh:mm:ss)
First Name in English Field length - VARIABLE C
minimum 1 character
maximum 50 characters
digits and special
characters other than a
minus (-) are not allowed
Last Name in English Field length - VARIABLE C
minimum 1 character maximum 50 characters
Full Name in English Field length - VARIABLE C
minimum 1 character,
maximum 120 characters
digits and special
characters other than a minus (-) are not allowed
First Name in Arabic Field length - VARIABLE C
minimum 1 character
maximum 50 characters
digits and special
characters other than a
minus (-) are not allowed
Last Name in Arabic Field length - VARIABLE O
minimum 1 character
maximum 50 characters
digits and special
characters other than a
minus (-) are not allowed
Full Name in Arabic Field length - VARIABLE C
minimum 1 character
maximum 120 characters
digits and special
characters other than a
minus (-) are not allowed
Date of Birth Field length FIXED, O
8 character (ddmmccyy)
Gender Field length FIXED M
1 character
Source Gender Type
Table
Title (Mr/Ms/Mrs) Field length - VARIABLE O
minimum 1
Character
maximum 20 characters
digits are not allowed
Source Title Type Table
Resident Flag Field Length FIXED, O
1 character
 Source Yes No Type Table
Nationality Field length FIXED, C
2 characters
Source Country Codes
Table
Passport # Field length - VARIABLE O
minimum 1 character,
maximum 20 characters
PassportExpiryDate Field length FIXED, O
8 character (ddmmccyy)
DrivingLicenseNumber Field length - VARIABLE C
minimum 1 character,
maximum 20 characters
EmiratesID Field length VARIABLE, C
minimum 15 character
(without separators),
maximum 18 characters
(with separators)
Allowed characters: Digits
and -(minus) symbol
Address Field length - VARIABLE O
minimum 1 character,
Maximum 200 characters
Alphanumeric
Address in Arabic nVarchar (200) O
Emirates Address Field length - FIXED1 O
character
Source Emirate Type
Table
Plot Number Field length - VARIABLE O
minimum 1 character,
maximum 10 characters
PoBox Field length - VARIABLE O
minimum 1 character,
maximum 10 characters
Contact Phone Number Field length - VARIABLE O
minimum 1 character,
maximum 20 characters
Allowable characters:
digits plus(+) and spaces
Mobile Number Field length - VARIABLE O
minimum 1 character
maximum 20 characters
Allowable characters:
digits plus(+) and spaces
Additional Mobile Field length - VARIABLE O
minimum 1 character,
maximum 20 characters
Allowable characters:
digits plus(+) and spaces
Email Field length - VARIABLE O
minimum 1 character,
maximum 120 characters
Employer Name Field length - VARIABLE C
minimum 1 character,
 maximum 120 characters
Alphanumeric
EmployeDate Field length FIXED, O
8 characters
(ddmmccyy)
Termination Date Field length FIXED, O
8 characters
(ddmmccyy)
Gross Annual Income Positive Integer, O
minimum 1 digit,
maximum 12 digits
Employment Type Field length FIXED, O
2 characters
Source Employment Type
Table
Other Income Source Field length FIXED, C
2 characters
Source Income Source
Table
Other Income Amount Positive or Zero Integer, O
minimum 1 digit,
maximum 12 digits
Company
RecordID Positive Integer, M
minimum 1 digit
maximum 12 digits
ProviderSubjectNo Field length - VARIABLE M
minimum 1 character
maximum 16 characters
Alphanumeric,
No special characters
except underscore ( _ )
and Minus (-) are allowed
DateOfLastUpdate Field length FIXED, M
16 characters
(ddmmccyyhh:mm:ss)
Trade Name Field length - VARIABLE C
minimum 1 character,
maximum 120 characters
Alphanumeric
Trade Name Arabic Field length - VARIABLE C
minimum 1 character,
maximum 120 characters
Alphanumeric
Trade Registration Place Field length - VARIABLE O
minimum 1 character,
maximum 60 characters
Alphanumeric
Trade License Number Field length - VARIABLE M
minimum 1 character,
maximum 25 characters
Alphanumeric
DateOfEstablishme Field length FIXED, O
nt 8 characters
(ddmmccyy)
Emirates Address Field length - FIXED1 O
character
Source Emirate Type
Table
Plot Number Field length - VARIABLE O
minimum 1 character,
maximum 10 characters
PoBox Field length - VARIABLE O
minimum 1 character,
maximum 10 characters
Contact Phone Number Field length - VARIABLE O
minimum 1 character,
maximum 20 characters
Allowable characters:
digits plus(+) and spaces
Mobile Number Field length - VARIABLE O
minimum 1 character
maximum 20 characters
Allowable characters:
digits plus(+) and spaces
Additional Mobile Field length - VARIABLE O
minimum 1 character,
maximum 20 characters
Allowable characters:
digits plus(+) and spaces
Email Field length - VARIABLE O
minimum 1 character,
maximum 120 characters
LINK
RecordId Positive Integer, M
minimum 1 digit
maximum 12 digits
ProviderPrimarySu Field length - VARIABLE M
bjectNo minimum 1 character,
maximum 16 characters
Alphanumeric
No special characters
except underscore ( _ )
and Minus (-) are allowed
ProviderSecondary Field length - VARIABLE M
SubjectNo minimum 1 character,
maximum 16 characters
Role Field length FIXED, M
2 characters
Source Subject Role Type
Table
TerminatedFlag Field length FIXED, O
1 character
Source Yes No Type Table
The data for Contract from source has to come in csv format. Detail of field as below

Field DataType
Provider Code Field length VARIABLE M
minimum 1 character
maximum 5 characters
Alphanumeric
BatchID Field length - VARIABLE M
minimum 1 character,
maximum 16 characters
Alphanumeric
No special characters
allowed except
Minus (-)
Extract Date Time Datetime 8 char date M
(ddmmyyyy)
ModeType Field length FIXED M
1 character
Source: Mode Type Table
ProviderContractNo Field length - VARIABLE M
minimum 1 character,
maximum 35 characters
Alphanumeric, No special
characters except Minus (-)
are allowed
OriginalCurrency Field length FIXED, O
3 characters
Source Currency Codes Table
ReferenceDate Field length FIXED, 6 M
character (mmccyy)
ContractType Field length FIXED, M
2 characters
Source: Contract Type Table
ActiveFlag Field length FIXED, M
1 character
Source: Active Flag Type
OpenDate Field length FIXED, 8 M
character (ddmmccyy)
ClosedDate Field length FIXED, 8 C
character (ddmmccyy)
ContractStatus Field length FIXED, M
1 character
Source Status Type Table
ContractStatusDate Field length FIXED, N/A
8 characters
(ddmmccyy)
Installment
TotalAmount Positive Integer, M
minimum 1 digit,
maximum 12 digits
PaymentAmount Positive Integer, M
minimum 1 digit,
 maximum 12 digits
NoOfInstalments Positive Integer, M
minimum 1 digit,
maximum 3 digits
NoOfRemainingIns Positive or Zero Integer, M
talments minimum 1 digit,
maximum 3 digits
MethodOfPayment Field length FIXED, O
3 characters
Source Method of Payment
Type
PaymentFrequency Field length FIXED, M
1 character
Source PaymentFrequency
table
Default is M
Balance Positive or Zero Integer, M
minimum 1 digit,
maximum 12 digits
OverdueAmount Positive or Zero Integer, M
minimum 1 digit,
maximum 12 digits
Default is zero
DaysPaymentDelay Field length FIXED, M
1 character,
Source DPD Type Table
Default is 0
IslamicContractFlag Field length FIXED, O
1 character
Source Yes No Type Table
Default is based on banks
SecuredContractFlag Field length FIXED, O
1 character
Source Yes No Type Table
NotInstalment
CreditLimit Positive or zero Integer, M
minimum 1 digit,
maximum 12 digits
Balance Positive or zero Integer, M
minimum 1 digit,
maximum 12 digits
OverdueAmount Positive or Zero Integer, O
minimum 1 digit,
maximum 12 digits
DaysPaymentDelay Field length FIXED, O
1 character,
Source DPD Type Table
Default is 0
IslamicContractFlag Field length FIXED, O
1 character
Source Yes No Type Table
Default is based on banks
principles
SecuredContractFl Field length FIXED, O
ag 1 character
 Source Yes No Type Table
CreditCard
MethodOfPayment Field length FIXED, O
3 characters
Source Payment Type Table
Default value is CAS
PaymentFrequency Field length FIXED, M
1 character
Source Payment Frequency
Type Table
Default is M
CreditLimit Positive or zero Integer, M
minimum 1 digit,
maximum 12 digits
MinimumPayment Positive or zero Integer, M
Percentage minimum 1,
maximum 2 digits
Balance Positive or zero Integer, M
minimum 1 digit,
maximum 12 digits
OverdueAmount Positive or zero Integer, M
minimum 1 digit,
maximum 12 digits
CardUsedFlag Field length FIXED, M
1 character
Source Yes No Table
AmountSpentInMonth Positive or zero Integer, O
minimum 1 digit,
maximum 12 digits
MinimumPayment Field length FIXED, M
Flag 1 character
Source Yes No Table
MinimumPayment Field length FIXED, M
Flag 1 character
Source Yes No Table
DaysPaymentDelay Field length FIXED, M
1 character,
Source DPD Type Table
Default is 0
IslamicContractFlag Field length FIXED, O
1 character
Source Yes No Type Table
Default is based on banks
principles
SecuredContractFlag Field length FIXED, O
1 character
Source Yes No Type Table
Services
BilledAmount Positive or Zero Integer, M
minimum 1 digit,
maximum 12 digits
Balance Positive or Zero Integer, M
minimum 1 digit,
maximum 12 digits
OverdueAmount Positive or Zero Integer, M

DaysPaymentDelay
NoOfServices/Voice
NoOfServices/Data
NoOfServices/Other
CommunicationType
HolderIsNotLiable
RecordId
ProviderContractNo
ProviderSubjectNo
Role
3.2.3 User Maintenance
3.2.3.1Requirement Summary:
User management would be handled by the system .
minimum 1 digit,
maximum 12 digits
Field length FIXED, M
1 character,
Source DPD (Services only)
Type Table
Default is 0
Positive or Zero Integer, C
minimum 1 digit,
maximum 4 digits
Positive or Zero Integer, C
minimum 1 digit,
maximum 4 digits
Positive or Zero Integer, C
minimum 1 digit,
maximum 4 digits
Field length FIXED, C
characters 2
Source Communication Type
Table
Field length FIXED, O
1 character
Source Yes No Type Table
Link
Positive Integer, M
minimum 1 digit
maximum 12 digits
Field length - VARIABLE M
minimum 1 character,
maximum 16 characters
Alphanumeric,
No special characters except
underscore ( _ ) and Minus
(-) are allowed
Field length - VARIABLE M
minimum 1 character,
maximum 16 characters
Alphanumeric
No special characters except
underscore ( _ ) and Minus
(-) are allowed
Field length FIXED, 1 Refer to Contract Role Type table
character for valid values
Source Contract Role Type
Requirement Detail:

System would handle user management. It would provide ability to add new users/ update or
delete existing users. Also it would provide ability to create role based access to the system.

3.2.3.1.1 Implementation:

User Management module would be developed. It would contain following masters. All these
would be developed in Maker/Checker concept. Maker would add/edit/delete and checker would
verify it and approve. This helps in eliminating any manual error.

User Master: This screen facilitates you to create a user id and password. Also allow you to give
specific rights to the user based on the requirements.

To define the user:

1. Navigates to User Management > User Master

2. System displays the Country Name and Bank Name based on the logged in user.
3. Enter the unique user name. The field type is alphanumeric and special
characters with maximum length of 25 characters.
4. Enter an authenticated password for login based on the limit set in Password
Policy Master.
5. Enter the login users full name. The field type is alphanumeric with maximum
length of 50 characters.
6. Enter the login users email address.
7. Select the relevant bank branch from where the user is logging into the
application.
8. Select the required user group such as Operator, Maker, Checker and so on.
9. Select the limit based on which the user has the authority to clear the cheques.
10. Select the required transaction type based on the requirement.
11. Select the bank region of the logged in user.
12. Select the checkbox Is Active to activate the user.
13. Select the checkbox Is Checker to give checker rights to the created user.
14. Save the information such that the data display in the grid

User Group Master: This screen is used to group the user based on which the users are
provided transaction access privilege. The association of user to the defined group is performed
in User Master Screen.

To define user group:

1. Navigate to User Masters >User Group Master.

2. System displays the Country Name and Bank Name based on the logged in user.
3. Click Add New button to enter the new record. You are allowed to view the Add
Group screen, once the button is clicked. Enter the relevant fields as follows:
 i. Group Code Unique group code. The field type is alphanumeric with maximum of 5
characters (without space).
ii. Group Name Name of the group. The field type is alphanumeric with
maximum of 100 characters (with space).
iii. Group Description Descriptions about the group to be created.

1. Click Save button to save the defined details in the database. The
saved details displays in the grid as shown in the above screenshot.
2. System lists the defined user group in the User Group field of User Master
screen.

Role Master: This screen aids you to define the roles such as Operator, Supervisor and so on.

To define the role:

1. Navigate to User Management > Role Master.

2. System displays the Country Name and Bank Name based on the logged in user.
3. Enter the unique code of the role to be defined. The field type is alphanumeric
with maximum of 5 characters.
4. Enter the role name which is to be defined. The field type is alphanumeric with
maximum of 50 characters.
5. Optionally, enter the description about the role.

1. Save the information. The saved details displays in the grid

Assign Role: This screen facilitates you to provide user access to the required screens based on
the defined role.

To assign the role:

1. Navigate to User Management > Assign Role.

2. System displays the Country Name and Bank Name based on the logged in user.
3. Select the relevant role for which the screen access to be provided.
4. Select the relevant access rights for the available screens as per the
requirement:

i. IsRead The user can only view the screen and not allowed to do any modification.
ii. IsWrite - The user can view and modify the data as per the requirement.

5. Save the information

.

Role Group Master: This screen aids you to define a group based on which Bank, Branch and
Region are associated, respectively. The defined group can be viewed in the respective masters
(Bank, Branch and Region).

To define a group:

Navigate to Masters > Group Master.

System displays the Country Name and Bank Name based on the logged in user.

Enter the unique code of group to be defined. The field type is alphanumeric with maximum of 5
characters.

Select any one of the following group based on the requirement.

Bank
Branch

Region

Enter the unique name of the group to be defined. The field type is alphanumeric with maximum
of 50 characters.

Save the information. The saved details displays in the grid.

Password Policy: This would be provided to enforce password policy for users. A screen would be
provided to configure password policy for the system. Once configured the policy would be
applicable for all users.

Reser Password: This screen would be provided to reset password, if the user forgets the
password.

3.2.4 Master Maintenance

3.2.4.1Requirement Summary:

Masters would be maintained by the system.

Requirement Detail:

System would maintain masters. It would provide ability to add / edit / delete master data.
3.2.4.1.1 Implementation:

Master Maintenance module would be developed. It would contain following masters. All these
would be developed in Maker/Checker concept. Maker would add/edit/delete and checker would
verify it and approve. This helps in eliminating any manual error. Add/Edit/Search/Delete
functionalities would be provided

Currency Master: This screen enables you to define the currency details through which the
transaction is to be carried out. You have the facility to define multiple currencies.

To define a currency:

Navigate to Masters > Currency Master

System displays the Country Name and Bank Name based on the logged in user.
Click Add New button to enter the new record. You are allowed to view the Add Currency
screen, once the button is clicked. Enter the relevant fields as follows:
Currency Code Unique code of the currency. The field type is alphanumeric with maximum of 3
characters (without space).
Currency Name Unique name of the currency. The field type is alphanumeric with maximum of
25 characters (with space).
Conversion Rate The exchange rate of the currency through which transaction is performed.
The field type is numeric with maximum of 13 digits with 2 decimals. Example.
if the base currency is 'Dirham' and the transactions are carried out in functional currency namely
'USD', then the exchange rate should be defined as follows:

1 Dirham = 0.114 USD

Save the information. The saved details displays in the grid.

Country Master: This screen enables user to define the country, where the application is
implemented. It provides facility to define multiple country details.

To enter the country details:

Navigate to Masters > Country Master

Click Add New button to enter the new record. System displays the Add Country screen, once
the button is clicked. Enter the relevant fields as follows:
Country Code Unique Country code. The field type is alphanumeric with maximum of 5
characters (without space).
Country Name Name of the country. The field type is alphanumeric with maximum of 50
characters (with space).
Currency Name Select the relevant currency. System lists out the currency names, defined in
the currency master.
Save the information. The saved details displays in the grid.

3.2.5 Home Dashboards

3.2.5.1Requirement Summary:

Dashboard would be provided by System in Home page

Requirement Detail:

Dashboard would be provided by System in Home page. This would display key data that would
be useful for business.

3.2.5.1.1 Implementation:

Home dashboard would contain following data in tabular format.

Subject to CB:Total/ Accepted/ Rejected

Contract to CB: Total/ Accepted/ Rejected
Subject correction: Total / Pending/ Corrected
Contract Correction: Total/ Pend/ corrected
Subject Resent to CB: Total/ Accepted/ Rejected
Contract Resent to CB: Total/ Accepted/ Rejected

This would also be available as pie chart.

3.2.6 Initial Data Submission

3.2.6.1Requirement summary:

Initial submission (load) of existing Contracts to CB.

Requirement Detail:

Credit Provider should submit Subject File to Credit Bureau. This contains information of the
contract holders and of the links between Subjects.

When a Credit Provider agrees to submit to the Credit Bureau it must provide an initial load of
Contract Data and Subject Data. There are three pairs of files (Subject and contract) that need to
be submitted:
The current months active contracts
The 23 previous months active contracts
All written off contracts in the last 2 years.

3.2.6.1.1 Implementation:

All the above mentioned detail would be downloaded from core banking system and maintained
in local DB. When a Credit provider set up with Credit Bureau for providing credit data, this data
would be sent to CB using VLink.
3.2.7 Periodic Subject Data Submission

3.2.7.1Requirement summary:

Credit Provider should submit Subject and Contract data periodically every month to CB.

Requirement Detail:

Subject File contains information of the contract holders and of the links between Subjects.
Contract data file contains information of the contracts and of the links between the Contracts and
their contract holders.

Each submission is made by two files (Subjects and Contracts); the two files are zipped and the
zipped file can be encrypted. Name of the Subject file is [ProviderCode]_SRPT.xml. Name of the
Contract file is [ProviderCode]_CRPT.xml. Name of the zipped file that includes both of the above
files is [BatchId]_[ProviderCode]RPT.zip where BatchId is the unique identifier assigned by the
Credit Provider to the submission. When the file is encrypted, the name of the encrypted file
should be [BatchId]_[[ProviderCode]RPT.zip.pgp The bureau will only process them once there
are two files present with the same batch ID; if not it will raise an error.

Batch ID: Each Data submission is identified by the BatchId which is a unique identifier for each
Credit Provider.
The BatchId should be a sequential number where each number is used once, and the next
number in the sequence is used in the following submission. Providers may add further
intelligence to the number (e.g. portfolio name [cards00001] or date [YYMM001]).
The same BatchId is used in the Subject file and the contract file. This ensures that they are
processed as a pair.
The same BatchId should never be reused by the Credit Provider.
The BatchId is indicated in the submission file name and inside the Header of the Subject file and
of the Contract file.

RecordId: RecordId is the unique identifier of the multi occurrence elements Individual,
Company, Link in the Subject file and of the multi occurrence elements Instalment,
Al Etihad Credit Bureau 2013 Page 13 of 101
NotInstalment, CreditCard, Service, and Link in the Contract file. This is a progressive number
that should be unique inside each file and it allows the Credit Bureau to identify exactly the
element in each file. This number is used in Error files sent back to Credit providers to identify the
records containing errors.

Quality of data submitted : Credit Providers must ensure the information they submit to the Al
Etihad Credit Bureau is accurate, complete and up-to-date.

Timeliness of data submission: Credit Providers must develop the necessary processes,
procedures and systems to submit data to the Al Etihad Credit Bureau in a timely manner they
must make best endeavors to extract data no more than 3 days after the end of the submission
period and submit it no later than the 10th day of the following month.
The submission period is the month that has just passed for all contract types.

All Active Contracts should be submitted to the Credit Bureau: All Active Contracts
regardless of whether their information changed from the previous submission should be
submitted to the Credit Bureau.

When Subject data should be submitted: Subject data should be submitted in one of the
following cases:
- A new contract is submitted in the contract file that refers to a Subject that was never submitted
before by the Credit Provider
- A new Subject (never submitted before by the Credit Provider) is added as Guarantor/Co-
Contract holder in the Link section of the Contract file
- Some data relating to an existing Subject is updated and the Credit Provider must inform the CB
In other cases it is not mandatory to submit Subject data although it is not forbidden.

Type of Subjects: Subject file allows Credit Providers to submit Individuals and Companies; Sole
Traders and SME (Small Medium Enterprises) should be submitted as Companies.

Subject file in case no changes occurred on any Subjects: If there are no changes, on any
single Subject, the Credit Provider will still have to send a Subject file, but this will contain just
Header info. Data submission should always include both files, so when Credit Provider will send
a Contract File they should send also a Subject File with the same BatchId identifier.

Frequency of submission: After initial submission of all existing Contracts its necessary to
submit any active Contract or Contracts that have been Closed since the last submission period
on a monthly basis. Closed contracts are contributed only once. The Credit Provider should aim
to produce their files for submission within 3 working days of the end of the month and the Credit
Provider must submit their data by the 10th day of the month at the latest.

Consistency in frequency of submission: The frequency with which a Credit Provider submits
data should be consistent over time.

Permitted data based on Contract type: Credit Providers must only submit data required for
each Contract type in the format described by Data Dictionary document.

3.2.7.1.1 Implementation:

The subject and contract data would be downloaded from core banking system and maintained in
local DB. This data would be periodically (monthly) sent to CB using VLink.

Subject file format sent to CB

Contract file format sent to CB

Error file from CB

Cheque Retrun Input File Format:

Field Name M/C/O Data Type & Size Comments

Header
Record Type M Char(1) Always H
Field length FIXED 1
character
ProviderCode M Varchar(5)
Field length - VARIABLE
minimum 1 character
maximum 5 characters
Alphanumeric
BatchId M Varchar(16)
Field length - VARIABLE
minimum 1 character,
maximum 16 characters
Alphanumeric
 No special characters allowed
except underscore ( _ ) and
Minus (-)
RecordTotalNo M Numeric(12,0)
Positive Integer minimum 1
digit ,maximum 12 digits

Detail
Record Type M Char(1) Field length FIXED 1
character.

RecordId M Varchar(12)
Positive Integer,
minimum 1 digit
maximum 12 digits
Subject Type M Char(1)
Field length FIXED 1
character.
Source Subject Type Table

FullNameEN C Varchar(120)
Field length - VARIABLE
minimum 1 character,
maximum 120 characters
digits and special characters
other than a minus (-) are not
allowed
DOB O DATE
Field length FIXED,
8 character (ddmmccyy)
Nationality C Char(2)
Field length FIXED,
2 characters
Source Country Codes Table
PassportNo C Varchar(20)
Field length - VARIABLE
minimum 1 character,
maximum 20 characters
EmiratesId C Varchar(18)
Field length VARIABLE,
minimum 15 character
(without separators),
maximum 18 characters (with
separators)
Allowed characters: Digits and
-(minus) symbol
TradeNameEN C Varchar(120)
Field length - VARIABLE
minimum 1 character,
maximum 120 characters
Alphanumeric
Trade License No. C Varchar(25)
Field length - VARIABLE
minimum 1 character,
maximum 25 characters

Registration Place
Type of Payment
Order
Alphanumeric
O Varchar(60)
Field length - VARIABLE
minimum 1 character,
maximum 60 characters
Alphanumeric
M Char(1)
Field length FIXED 1
character.
Source Payment Order Type
Table

Bank Identifier M Varchar(5)

Field length - VARIABLE
minimum 1 character
maximum 5 characters
Alphanumeric
Beneficiary Name O Varchar(120)
Field length - VARIABLE
minimum 1 character
maximum 120 characters
Alphanumeric
IBAN M Varchar(28)
Field length - VARIABLE
minimum 23 characters
maximum 28 characters
Alphanumeric
Cheque/Direct M Varchar(10)
Debit No. Field Length - VARIABLE
minimum 1 character,
maximum 10 Characters
Amount M Numeric(9,2)
Positive Integer
minimum 1 digit, maximum 9
digits
Reason Code M Char(1)
Field length FIXED
1 character
Source Reason Code Table
Date of Return M DATE
Field length FIXED,
8 character (ddmmccyy)
Reference Date M DATE
Field length FIXED,
8 character (ddmmccyy)

Cheque Output file Format:

Field Name M/C/O Data Type & Size

Header
Record Type M Char(1)

ProviderCode M Varchar(5)

BatchId M Varchar(16)
RecordTotalNo M Numeric(12,0)
Detail
Record Type M Char(1)

RecordId M Varchar(12)
Subject Type M Char(1)
FullNameEN C Varchar(120)
FullNameAR C nVarchar(120)
DOB O DATE
Nationality C Char(2)
PassportNo C Varchar(20)
EmiratesId C Varchar(18)
TradeNameEN C Varchar(120)
Trade License No. C Varchar(25)
Registration Place O Varchar(60)
Type of Payment Order M Char(1)
Bank Identifier M Varchar(5)
Beneficiary Name O Varchar(120)
IBAN M Varchar(28)
Cheque/Direct M Varchar(10)
Debit No.
Amount M Numeric(9,2)

Reason Code (Refer M Char(1)

Mapping Table)
Date of Return M DATE
Reference Date M DATE

DDS Input Format

Field Name M/C/O Data Type Comments

& Size
Header
Record Type M Char(1) Always H

ProviderCode M Varchar(5) Available

BatchId M Varchar(16) Available

RecordTotalNo M Numeric(12,0) Available

Detail
Record Type M Char(1 Always R
RecordId M Varchar(12) Available
Subject Type M Char(1) Available
FullNameEN C Varchar(120) Available
DOB O DATE Not Available
Nationality C Char(2) SCB This element is mandatory when the
PassportNo is filled; in other case it is
optional. The field should be filled when the
 Subject Type=1 (Individual).
Refer to Country Codes table for valid values
PassportNo C Varchar(20) Taken from DDS System based on Customer
ID Type.Incase of CustomerID Type selected
as Family Book Number,Driving License
Number then SCB need to provide passport
Number.
EmiratesId C Varchar(18) Taken from DDS System based on Customer
ID Type.Incase of CustomerID Type selected
as Family Book Number,Driving License
Number then SCB need to provide
EmiratesId.
TradeNameEN C Varchar(120) Available (Payer Name)
Trade License No. C Varchar(25) Available
Registration Place O Varchar(60) Not Available
Type of Payment M Char(1) Available
Order
Bank Identifier M Varchar(5) Available

Beneficiary Name O Varchar(120) Available (Payee name)

IBAN M Varchar(28) Available

Cheque/Direct M Varchar(10) Available (DDA Reference Number)
Debit No.
Amount M Numeric(9,2) Available

Reason Code M Char(1) Available

Date of Return M DATE Available

Reference Date M DATE Available

DDS Output Format.

Field Name M/C/O Data Type & Size

Header
Record Type M Char(1)

ProviderCode M Varchar(5)

BatchId M Varchar(16)
RecordTotalNo M Numeric(12,0)
Detail
Record Type M Char(1)

RecordId M Varchar(12)
Subject Type M Char(1)
FullNameEN C Varchar(120)
FullNameAR C nVarchar(120)
DOB O DATE
Nationality C Char(2)
PassportNo C Varchar(20)
EmiratesId C Varchar(18)
TradeNameEN C Varchar(120)
Trade License No. C Varchar(25)
Registration Place O Varchar(60)
Type of Payment Order M Char(1)
Bank Identifier M Varchar(5)
Beneficiary Name O Varchar(120)
IBAN M Varchar(28)
Cheque/Direct M Varchar(10)
Debit No.
Amount M Numeric(9,2)

Reason Code M Char(1)

Date of Return M DATE
Reference Date M DATE

3.2.8 Data Updation

3.2.8.1Requirement summary:

This section covers the requirements for updating the data by the Credit Provider of their
previously submitted data held by the Al Etihad Credit Bureau.

Requirement Detail:

Submitted data differs to data held by Credit Bureau: If a data element submitted to the Credit
Bureau for a Contract /Subject differs from the data element as it is recorded by the Al Etihad
Credit Bureau for the Contract/Subject and the data element is a permitted updateable data
element then the Al Etihad Credit Bureau will apply any necessary updates.
If a data element submitted to the Al Etihad Credit Bureau for a Contract/Subject does not differ
no action will be taken by the Al Etihad Credit Bureau for the data element.

Changes to Contract Holder identity detail: If Contract Holder identity details have changed
Credit Providers must supply the updated identity data. This ensures the Credit Bureau can keep
Subject data updated. Where data supplied by two Credit Providers is contradictory, the freshest
data will be used to determine the current data and the older data will be held as history. The
freshness of the data will be determined from the DateOfLastUpdate field in the data. If the
DateOfLastUpdate of the Subject record in input is more recent than the existing one in the
database that refers to the matched Subject the Subject info in the database will be updated; if
the DateOfLastUpdate is not more recent, the Subject info in the database will be kept as the last
provided and this will be displayed in the Credit Report. Data collected during enquiries will not
update the corresponding data held in the database.

3.2.8.1.1 Implementation:
The subject and contract data if there is a change would be downloaded from core banking
system and maintained in local DB. This data would be sent to CB using VLink.

3.2.9 Data Submission for Portfolio Transfer

3.2.9.1Requirement summary:

This section covers the Functional Requirements in case of Changes of ProviderSubjectNo

and/or ProviderContractNo. This happens when portfolio is transferred from a Credit Provider to
another one or when the portfolio numbering system is rearranged by the same Credit Provider
(e.g. a new banking platform is introduced or account numbers have an extra digit added) ..

Requirement Detail:

Transfer of Contract to other CP: When ownership of a Contract is transferred from one Credit
Provider to another, both Credit Providers (seller, buyer) are required to submit transfer details to
the Credit Bureau. The seller and buyer will need to coordinate this activity to ensure successful
transfer. It is recommended to also engage the Credit Bureau in this process.
The following must be observed
- The seller has already submitted Contract Id and details to the Credit Bureau
- The seller has already submitted the transfer before the buyer submits their file of the Contracts.

Subject and Contract Data: Credit Provider should submit following two files to the Credit
Bureau: -
SubjectNoChanges File: contains information of the Provider Subject No Changes -
ContractNoChanges File: contains information of the Provider Contract No Changes.

File name convention of transfer: Each submission is made by two files (SubjectNoChanges
and ContractNoChanges); the two files are zipped.
Name of the SubjectNoChanges file is [ProviderCode]_SNCRPT.xml
Name of the Contract file is [ProviderCode]_CNCRPT.xml
Name of the zipped file that includes both previous files is [BatchId]_[ProviderCode]SCNRPT.zip
where BatchId is the unique identifier assigned by the Credit Provider to the submission.

Change limited to ProviderSubjectNo or ProviderContractNo: Where the Credit Provider only

changes the ProviderSubjectNo or ProviderContractNo, both files should be submitted and the
Credit Provider should fill just the Header of the file without any elements to be changed (Change
node should not be filled). This is typically used where one Credit Provider buys another Credit
Provider and merges the businesses under one brand without merging the accounting platforms

BatchId : In Data submission for Portfolio Transfer, BatchId description is consistent with ordinary
contribution.
Each Data submission is identified by the BatchId which is a unique identifier for each Credit
Provider.
The same BatchId should never be reused by the Credit Provider.
The BatchId is indicated in the submission file name and inside the Header of the Subject file and
of the Contract file. The BatchId of the Contracts file and the Subjects file must be the same

RecordId: RecordId is the unique identifier of the elements in the file. This is a progressive
number that should be unique inside each file and it allows the bureau to identify the data
elements in each file. This number is used in Error files sent to Credit providers to refer to errors
detected in the data submission.
3.2.9.1.1 Implementation:

The subject and contract data if there is a portfolio transfer would be downloaded from core
banking system and maintained in local DB. This data would be sent to CB using VLink.

3.2.10 CB Response Processing

3.2.10.1 Requirement summary:

This section covers the requirements for verifying the data load processing results ..

Requirement Detail:

After loading a file of data received from a Credit Provider, the Al Etihad Credit Bureau will
generate a corresponding response file; this will be used by Al Etihad Credit Bureau to manage
their processes of data loading. The response file will provide summary processing statistics like
No. of total records loaded, No. of correct records, No. of records with errors, etc.

If any data elements within a set of Contract information or a set of Subject information or Link
information fail validation the record will be included in an error file with error details that will be
returned to the Credit Provider.

3.2.10.1.1 Implementation:

Response file would be received from CB. This would be in a shared location. Vlink would be
used to read this file and update local DB. First it would be moved to temp table and then
validation would be done. Success records would be updated in main table with status as
Success. Failed records would be moved to error queue table. From there these records would
be displayed in error queue.

3.2.11 Data Correction Rectification

3.2.11.1 Requirement summary:

This section contains general requirements relating to the rectification of the rejected data for re-
submission.

Requirement Detail:

Credit Providers must assess any rejected data record and where necessary rectify the cause of
the issue and the data to be submitted to the Al Etihad Credit Bureau: this can be done sending
the contract with ModeType=C as described in the Section 5.1.3.

Where a single or common issue (e.g. a software issue that resulted in the failure of a data
extraction or load process) has caused the rejection of data, Credit Providers must treat the issue
as a top priority incident, and ensure resolution of the issue in a timely manner. Failure to re-
establish Data submission that meets the quality requirements in 60 days will result in any
services being suspended for the Credit Provider.

3.2.11.1.1 Implementation:

Once system receive the error file from CB, the error records would be updated in error table in
DB. These error records would be available in error repair Queue screen in the system, User can
select an error record and correct it and save. Once all the error records are corrected,
resubmission is to be performed by the system.

3.2.12 Encryption Service

3.2.12.1 Requirement summary:

This describes encryption requirement of the data submission to CB.

Requirement Detail:

Credit Providers should encrypt and zip the subject and contract files before sending it to CB.
When the file is encrypted, the name of the encrypted file should be
[BatchId]_[[ProviderCode]RPT.zip.pgp The bureau will only process them once there are two files
present with the same batch ID; if not it will raise an error

3.2.12.1.1 Implementation:

A windows service would be provided to encrypt and zip the subject and contract file. This sevice
would peek the local shared path and on arrival of the files it would encrypt them and zip and
place it in the local shared path for movement to CB Shared path by AutoFTP.

3.2.13 Decryption Service

3.2.13.1 Requirement summary:

This describes decryption requirement of the data received from CB.

Requirement Detail:

Credit Providers should unzip and decrypt the subject and contract files after receiving from CB.

3.2.13.1.1 Implementation:

A windows service would be provided to unzip and decrypt the subject and contract file. This
sevice would peek the local shared path and on arrival of the files it would unzip and decrypt
them and place it in the local shared path for movement to DB by VLink.
3.2.14 Configuration Maintenance

3.2.14.1 Requirement summary:

This describes Configuration maintenance.

Requirement Detail:

Configuration of validation rules have to be maintained.

3.2.14.1.1 Implementation:

A screen would be provided to configure validation rules.

3.2.15 Audit

3.2.15.1 Requirement summary:

This describes Audit Component.

Requirement Detail:

System would provide Audit component to capture user footprints. Data should be captured to
show the complete foot prints of a user. This would provide a means to select a user, and see that
users activities filtered by dates.

3.2.15.1.1 Implementation:

Transaction Activity component would be developed to record all user activites. .

An audit Report would be provided to show user activities and would display old value and new
value in case of any updates. It would provide options to filter by date range or by type of activity
like Insert/Update/Delete.

3.2.16 Standard Reports

3.2.16.1 Requirement summary:

This describes standard reports.

Requirement Detail:

Standard reports like following would be provided.

Subject listing

This would show all the subjects available based on filter.

Filter condition would be for following.

Subject Type dropdown with Individual and Company as values

Date of Last Update
Provider SubjectNo

For Individual following fields would be available

Field Data Type

Provider SubjectNo VARCHAR(20) 16 characters unique,
alphanumeric, no special char . underscore and
minus are allowed
Date of Last Update DateTime ddmmyyyyhh:mm:ss
First Name in English VARCHAR(50) max 50, no special char except
minus
Last Name in English VARCHAR(50) max 50, no special char except
minus
Full Name in English VARCHAR(120) max 120, no special char
except minus.
First Name in Arabic NVARCHAR(50) max 50, no special char
except minus
Last Name in Arabic NVARCHAR(50) max 50, no special char
except minus
Full Name in Arabic NVARCHAR(120) max 50, no special char
except minus
Date of Birth Datetime ddmmyyyy
Gender CHAR(1) 1 char
Title (Mr/Ms/Mrs) VARCHAR(20)
Resident Flag CHAR(1) Bool (y/n)
Nationality CHAR(2) Fixed
Passport # VARCHAR(20) alphanumeric
PassportExpiryDate Datetime 8 char date (ddmmyyyy)
DrivingLicenseNumber VARCHAR(20) 20 char (min 1 max 20)
EmiratesID VARCHAR(20) Min 15 (without separators)
max 18 (with sep) 18
Address1 VARCHAR(20) Plot No
Address2 VARCHAR(200) Street Address, city
Address3 VARCHAR(10) PO box no
Address4 VARCHAR(10) Emirates
Address in Arabic NVARCHAR(200)
Contact Phone # VARCHAR(20) Main phone number
Mobile # VARCHAR(20)
Additional Mobile # VARCHAR(20)
Contact Email VARCHAR(120)
Employer Name VARCHAR(120)
Emplyed date DATE
Termination Date DATE
Employment Type CHAR(2)
Other Income Source CHAR(2)
Other Income Amount DECIMAL(12,0)
For Company

Field Data Type

Provider SubjectNo VARCHAR(20) 16 characters unique,
alphanumeric, no special char . underscore and
minus are allowed
Date of Last Update DateTime ddmmyyyyhh:mm:ss
Trade Name in English VARCHAR(50) max 50, no special char except
minus
Trade Name in Arabic NVARCHAR(50) max 50, no special char
except minus
Trade Licence Registration place VARCHAR60) max 60, no special char except
minus.
Trade License Number VARCHAR(25) max 50 alphanumeric
Date of Establishment Date ddmmyyyy
Address1 VARCHAR(20) Plot No
Address2 VARCHAR(200) Street Address, city
Address3 VARCHAR(10) PO box no
Address4 VARCHAR(10) Emirates
Address in Arabic NVARCHAR(200)
Contact Primary Phone # VARCHAR(20) Main phone number
Mobile # VARCHAR(20)
Additional Mobile # VARCHAR(20)
Contact Email VARCHAR(120)

Subject Finder

This would be displaying report for a particular Subject

Contract Listing

This would show all contracts based on filter

Contract finder

Displays contract data based on the contract identifier.

Error queue report

Displays error record detail

3.2.16.1.1 Implementation:

Crystal reports would be used to develop above mentioned reports

4 COMPONENT REQUIREMENTS

N/A.
5 NON FUNCTIONAL REQUIREMENTS

Availability:

System availability would be maintained at 99%. This would also depend on SLA of the client.

Performance:

The response time of the application would be 5 seconds 95% of the time.
The response time of the application would be 60 seconds 99.99% of the time.

Security:

Security against most of the identified ethical hacking would be provided by integrating Security
module with the system.

Configuration Management:

System would be maintainable. It would handle changes without compromising on the integrity
due to changes. VSS would be used for configuration management.

Quality:

All the relevant product documents would be developed and enhanced periodically over time
based on the addition of new features.

Backup:

DB backup should be handled by client periodically.

Maintainability:

System development/enhancement would follow the defined Architecture and would be monitored
periodically for any Architecture deviation. Coding Standards would be defined and followed.
Refactoring would be performed periodically.
6 INTERFACE REQUIREMENTS

6.1 INTERNAL INTERFACE

The system would interface with VLink to export data from system to CB and import data from CB
to system.

6.2 EXTERNAL INTERFACE

File transfer from and to CB shared path would be handled by Auto FTP.
7 WORK FLOW
Note: After A (off-page reference) the flow would be same as in previous diagram.
APPENDIX A SAMPLE FILES
APPENDIX B SAMPLE SCREENS

Currency Master

Add Currency
Search Currency

Modify Currency
Country Master

Add Country

Search Country
User Definition:
Record Sent for Approval to Checker

User Group
Role Definition:
Assign Role:
Role Group:
Password Policy:
Reset Password: