Académique Documents
Professionnel Documents
Culture Documents
Amendment sheet
Revision Number Date Rational For Change & Ref. Of Change Sections
Reference Documents
Signed By
Sign-Off date
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.
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.
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
Currently unavailable
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.
The software will be deployed as web application. The following are the details of various
modules and its location.
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.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
3.2 DETAIL
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
3.2.2.1Requirement Summary:
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
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
minimum 1 digit,
maximum 12 digits
DaysPaymentDelay 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 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 Positive Integer, M
minimum 1 digit
maximum 12 digits
ProviderContractNo Field length - VARIABLE M
minimum 1 character,
maximum 16 characters
Alphanumeric,
No special characters except
underscore ( _ ) and Minus
(-) are allowed
ProviderSubjectNo Field length - VARIABLE M
minimum 1 character,
maximum 16 characters
Alphanumeric
No special characters except
underscore ( _ ) and Minus
(-) are allowed
Role Field length FIXED, 1 Refer to Contract Role Type table
character for valid values
Source Contract Role Type
3.2.3.1Requirement Summary:
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.
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.
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.
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.
Assign Role: This screen facilitates you to provide user access to the required screens based on
the defined 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.
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:
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.
Bank
Branch
Region
Enter the unique name of the group to be defined. The field type is alphanumeric with maximum
of 50 characters.
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.1Requirement Summary:
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:
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:
Country Master: This screen enables user to define the country, where the application is
implemented. It provides facility to define multiple country details.
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.
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:
3.2.6.1Requirement summary:
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.
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
Alphanumeric
Registration Place O Varchar(60)
Field length - VARIABLE
minimum 1 character,
maximum 60 characters
Alphanumeric
Type of Payment M Char(1)
Order Field length FIXED 1
character.
Source Payment Order Type
Table
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)
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
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)
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.1Requirement summary:
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.
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.
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.
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.
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.
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
Requirement Detail:
3.2.14.1.1 Implementation:
3.2.15 Audit
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:
Requirement Detail:
Subject listing
Subject Finder
Contract Listing
Contract finder
3.2.16.1.1 Implementation:
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:
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
The system would interface with VLink to export data from system to CB and import data from CB
to system.
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: