Minor Project Document

Program Name:

Harmonized Reporting Format 2014

Project ID-Name :

PTS ID - 201306269

Document Control
a. Document History
Version

Date

Status: <Draft
or Final>

Author

Comment / Changes from Prior Version

1.0

30th Sep,
2013

Draft

Pranay
Somyajula

Initial Version

2.0

21st Nov
2013

Final

Pranay
Somyajula

Final Design Specifications as per

system built

b. Document Reviewers/Approvers
Name

Position (e.g. Client Manager, Project

Manager etc.)

Reviewer
(only)

Reviewer and
Approver

Vinod Rajaram

Senior Vice President

Manivannan Ramasubbu

Vice President

Ashwani Handa

Vice President

Sheeba Janaki

Relationship Manager

Vidwat Thakar

Deputy Delivery Head

Bharat Trivedi

Enterprise Architect

CONTENTS
DOCUMENT PURPOSE
The Minor Development Document has been designed for use on small, simple projects. In just one document it includes
many of the SDLC deliverables. It contains the functional and technical solutions, identification of external interfaces,
development testing plans and results, any UAT specific information, release and backout plan, as well as contingency/DR
plans. Approvals must be obtained prior to commencement of construction.
Minor Development Template Version 6.2
Template Updated 05/13/2011

Copyright 2004 - Citi

All rights reserved. Information contained herein is for Internal use and may only be used for business purposes authorized
by Citi.
1/33

DESCRIPTION / OBJECTIVES........................................................................................................................................... 4

BUSINESS REQUIREMENTS............................................................................................................................................. 4
2.1
2.2
2.3
2.4
2.5
2.6
2.7

FUNCTIONAL REQUIREMENTS........................................................................................................................................ 6
3.1
3.2

Description / Objectives................................................................................................................................................ 4
Scope........................................................................................................................................................................... 4
Assumptions / Constraints / Dependencies..................................................................................................................5
Acceptance Criteria...................................................................................................................................................... 5
Description of Requirements........................................................................................................................................ 5
Regulatory and Legal Requirements............................................................................................................................6
Non-Functional Business Requirements......................................................................................................................6

Function Specifications................................................................................................................................................. 6
Non-Functional Requirements.................................................................................................................................... 10

TECHNICAL DESIGN........................................................................................................................................................ 12
4.1
Technical Approach.................................................................................................................................................... 12
4.1.1
Technical Specifications...................................................................................................................................... 13
4.1.2
Modules Created / Changed / Deleted................................................................................................................13
4.1.3
External Interfaces.............................................................................................................................................. 23
4.2
Database Design/Layout............................................................................................................................................ 23
4.2.1
Logical Data Model.............................................................................................................................................. 23
4.2.2
Physical Data Model............................................................................................................................................ 23
4.3
Design Considerations............................................................................................................................................... 23
4.4
Detailed Design.......................................................................................................................................................... 23

DEVELOPMENT TEST PLAN........................................................................................................................................... 23

5.1
Test Objective............................................................................................................................................................. 23
5.1.1
Test Strategy....................................................................................................................................................... 23
5.1.2
Entry and Exit Criteria......................................................................................................................................... 23
5.1.3
Test Scope........................................................................................................................................................... 24
5.2
Constraints on Testing................................................................................................................................................ 24
5.3
Technical Risk Identification....................................................................................................................................... 24
5.4
Test Requirements...................................................................................................................................................... 24
5.4.1
Preparation.......................................................................................................................................................... 24
5.4.2
Test Environments, Network Connections, Locations.........................................................................................25
5.5
DEVELOPMENT TEST Participants, Roles and Responsibilities..............................................................................25
5.5.1
Participants and Roles........................................................................................................................................ 25
5.6
Test Execution and Control......................................................................................................................................... 25
5.6.1
Test classes for Development Test......................................................................................................................25
5.7
Development Test Scripts: Test Cases.......................................................................................................................26

RELEASE AND BACKOUT PLAN..................................................................................................................................... 28

GLOSSARY OF TERMS.................................................................................................................................................... 28

APPENDICES.................................................................................................................................................................... 28
8.1
8.2
8.3
8.4
8.5
8.6

COUNTER PARTY Bucket Logic................................................................................................................................28

COUNTRY Bucket Logic............................................................................................................................................ 30
SYSTEM Bucket Logic............................................................................................................................................... 31
HRF 2014 Regulations............................................................................................................................................... 31
HRF Example XML message..................................................................................................................................... 31
HRF Structure of XML file......................................................................................................................................... 31
Page 2 of 33

8.7
8.8
8.9

HRF- Counter Party definitions................................................................................................................................... 31

HRF- Country codes................................................................................................................................................... 32
GLOSSARY................................................................................................................................................................ 32

Page 3 of 33

1 DESCRIPTION / OBJECTIVES
In December 2004 the Debt Management Offices (DMOs) of the Eurozone agreed on
a harmonised format for Primary Dealers (PDs) to report on their activity in eurodenominated government securities market from January 2006 onwards. The
harmonised reporting format has been developed by the Economic and Financial
Committee (EFC) Sub-Committee on EU Sovereign Debt Markets in co-operation with
the European Primary Dealers Association (EPDA).
The objective of the harmonization was to simplify production of the monthly reports
by the PDs that are active in multiple Eurozone markets, resulting in more detailed
and consistent reports to the DMOs.

2 BUSINESS REQUIREMENTS
2.1 Description / Objectives
Currently PDs report to DMOs on a monthly basis in an aggregated format. For each security type,
applicable filtering, enrichment and formatting is applied to trade data (aggregated sales and purchases per
security type) and grouped in an excel spreadsheet in 3 different tabbed categories (country vs. counterpart,
country vs. maturity and counterpart vs. maturity). These groupings can lead to inconsistencies between the
different excel tabs.
In line with the Harmonized Reporting Format 2014 requirements, going forward the reporting will be
performed by TR-Hub platform on a trade by trade basis.
This project is broken into two phases (Phase 1 and Phase -2) and current document scope is limited to
Phase 1.

2.2 Scope
Within Scope:

Pilot project for ORC architecture

Automation of Harmonized Debt Reporting (XML Format) for 10 euro zone countries where Citi has
Primary Dealership
Generic framework for report configuration
Process orchestration through Process Management Framework (PMF)
Out of scope:

Maker checker process automation

Finanzagentur report implementation for Germany (Excel Format)
MIS Reporting
Checkpoint implementation for process verification and validation with data reconciliation
Process logging mechanism for diagnosis and analysis

Page 4 of 33

2.3 Assumptions / Constraints / Dependencies

Critical Decisions:

OCEAN data warehouse is single source of truth for harmonized debt reporting
All intermediate and reference data exists in TR-Hub database
All technology stacks and respective infrastructure already available in TR-Hub architecture
All data containing date time should also cover time zone to resolve day-light saving time zone
conflicts.

Assumptions:

PMF has capability of notification generation (e-mail setup)

o Received confirmation from Arup in design doc review meeting dated 04/10/2013
There should be any pipe character in data set as data dump file containing pipe as data separator
o If data contains the pipe then escape character must be present to distinguish actual data
and separator

Constraints:

Aggressive timeframe.
Limited familiarity in ORC

Dependencies:

OCEAN should have point in time data for regularity requirements

TR-Hub should have all the reference and lookup data to support reporting requirements

2.4 Acceptance Criteria

Process implemented in line with new HRF 2014 regulations utilising TR Hub with
successful user testing.

2.5 Description of Requirements

Format and submission of report

New format to use raw data and reporting to be done on a trade by trade
basis on a single sheet with no security classification.
All transactions to be reported in Extensible Mark-up Language (XML)
transmission of the files to be carried out via e-mail.
HRF to be submitted to DMOs within 13 target (business) days of the end
of the month to which the activity contained within the report applies.
Report available for in TR Hub from 6th business day.
Page 5 of 33

Reportable Transactions:

Only outright purchases and sales on the primary and secondary

markets.
Reporting firm is always CGML
For trade type SALES/TRADER in Ocean only TRADER leg is reportable
Sale of a bond to a DMO in the framework of a buy back operation done
before maturity should be reported as 'S' (Sale). Transactions booked in
TPS as outright sale.
Repos, Buy and sell back, bond stripping and reconstitution (primary
market transactions), bond redemptions at maturity are not reportable.
Outright cancellations intra-month are non-reportable.
Intra-firm transactions are non-reportable.
Both the book and counterparty accounts must be within the same legal entity and FIRM
accounts.
Inter-firm transactions are reportable. These will be in the population by default.
Exclusion Rules:
o Originating system for Repos and Buy/Sell backs is Finance Workstation (FWS)
These trades are not available in Ocean
o Bond redemptions are booked against Mnemonics FICACTL and DROPCTL2.
These mnemonics are the counterparties on the trades.
o Bond stripping and reconstitutions are booked against Mnemonics SPSTRP
ITSTRP FRSTRP DESTRP ATSTRP NLSTRP BESTRP
These mnemonics are the counterparties on the trades.

Reportable Fields
S. No.
1
2
3
4

Field Name
Trade Date
Security
Transaction Type
Quantity

5
6

Counterpart
System

Country

Description
The date on which trade is concluded
ISIN Code
Buy or Sell Flag in PDs perceptive
Trade quantity in nominal value expressed in
units
Category of buyer or seller party
Source system from where trade has been
originated
Country of Incorporation

2.6 Regulatory and Legal Requirements

N/A

2.7 Non-Functional Business Requirements

N/A

Page 6 of 33

3 FUNCTIONAL REQUIREMENTS
3.1 Function Specifications
Below table describes the key requirement of each KBR defined in Business Requirement Document
version 5.0 including scope targeted for Phase 1 and Phase 2.
KBR

Key Requirement

1
1.1

Format and Submission of the Report

New format to use raw data and reporting to be done on trade by trade basis
on single file with no security classification.
All transactions to be reported in Extensible Markup Language (XML) as
opposed to Excel and transmission of the files to be carried out via e-mail.
HRF to be submitted to DMOs within 13 target (business) days of the end of
the month to which activity contained within the report applies.
Report available in TR Hub from 6th Business Day.
Reportable Transactions
Only outright purchases and sales on the primary and secondary markets
Reporting firm is always CGML
Consume source system data in OCEAN from TPS
For trade type, SALES/TRADER in OCEAN only TRADER leg is reportable
Sale of a bond to a DMO in the framework of buy back operation done before
maturity should be reported as S (Sale). Transaction booked in TPS as
outright sale.
Repos, Buy and sell back, bond stripping and reconstitution, bond redemptions
at maturity are not reportable
Exclusion Rules:
1. Originating system for Repos and Buy/Sell backs is Finance Workstation
(FWS). These trades are not available in OCEAN.
2. Bond redemptions are booked against mnemonics FICACTL and
DROPCTL2. These mnemonics are the counterparties on the trades.
3. Bond stripping and reconstitutions are booked against mnemonics
SPSTRP, ITSTRP, FRSTRP, DESTRP, ATSTRP, NLSTRP, BESTRP.
These mnemonics are the counterparties on the trades.
Outright cancellations intra-month are not reportable
Intra-firm transactions are not reportable
Exclusion Rule : Both the book and counterparty accounts must be within the
same legal entity and FIRM accounts. These trades are not available in
OCEAN.
Inter-firm transactions are reportable. These will be in the population by default.
Reportable Securities
Euro denominated government securities issued by Eurozone DMOs.
Golden source to be used for product identification is SECURE.
Inclusion Rules :
IsCrcy = EUR and
IsCntry = FRA or ITA or ESP or BEL or AUT or FIN or GRC or IRL or
NLD or PRT and
FiInstTypC = SEC and
FiTypC = GOVT and
FiSubTypeC = BILL or BOND or GVTB or SRTP or OTHB or N/A or
NULL and

1.2
1.3
1.4
2
2.1
2.2
2.3
2.4
2.5
2.6
2.6.1

2.7
2.8
2.8.1
2.9
3
3.1
3.1.1

Target
Phase
Phase 1
Phase 1
Phase 1
Phase 1
Phase 1
Phase 1
Phase 1
Phase 1
Phase 1
Phase 1
Phase 1

Phase 1
Phase 1
Phase 1
Phase 1
Phase 1
Phase 1

Page 7 of 33

Where IsrCntry = FRA Report to be sent to French DMO

Where IsrCntry = ITA Report to be sent to Italian DMO
Where IsrCntry = ESP Report to be sent to Spanish DMO
Where IsrCntry = BEL Report to be sent to Belgian DMO
Where IsrCntry = AUT Report to be sent to Austrian DMO
Where IsrCntry = FIN Report to be sent to Finnish DMO
Where IsrCntry = GRC Report to be sent to Greek DMO
Where IsrCntry = IRL Report to be sent to Irish DMO
Where IsrCntry = NLD Report to be sent to Dutch DMO
Where IsrCntry = PRT Report to be sent to Portuguese DMO
3.2.1

Inclusion Rule:
Where IsrCntry = GER Report to be sent to German DMO

Phase - 2

3.2

PDs are no longer required to determine reportable security types. The ISIN
code determines whether or not a transaction is reportable
Reportable Fields
Trade Date
The date on which the trade is concluded. Not the trade value or entry date

Phase 1

4.1.2
4.1.3

Format of trade date to be YYYY-MM-DD

Exception Queue :
a) If trade date value is missing or formulated incorrectly (Technical Exception)
b) If trade date is in future (Business Warning) [User can accept/ignore.
Comment box to be provided (Not Mandatory)]

Phase 1
Phase 2

4.2
4.2.1
4.2.2

Security
ISIN code to be provided on all transactions
Exception Queue :

4
4.1
4.1.1

Phase 1

Phase 1
Phase 2

a) If TR Hub takes in the FII

- Blank value. No FII available (Technical Exception)
- No ISIN on lookup (Business Exception) [User can accept/ignore. Comment
box to be provided (Not Mandatory)]
b) If TR Hub takes in the ISIN
- Blank value. No ISIN available (Technical Exception)

4.3
4.3.1
4.3.2
4.3.3
4.4
4.4.1
4.4.2
4.4.3
4.4.4
4.4.5

c) If security has FiSubTypeC = OTHB or N/A or NULL (Business Warning)

[User can accept/ignore. Comment box to be provided (Not Mandatory)]
Transaction Type
The transaction type should always be reported from PDs perceptive. Indicator
to be flipped if OCEAN/TPS is reflecting trades from CPs perceptive
Available Options : B for Buy ; S for Sale
Exception Queue :
If the value is anything other than B or S (Technical Exception)
Quantity
The turnover to be reported is the nominal value expressed in units and no
rounding should be made
No sign conversion to be applied to the transactions
The maximum number of decimals that can be used is 2. The decimal
separator is .
No 1000 separator can be used
Exception Queue :
If the value is blank or non-numeric (Technical Exception)

Phase 1
Phase 1
Phase 2
Phase 1
Phase 1
Phase 1
Phase 1
Phase 2

Page 8 of 33

4.5
4.5.1
4.5.2
4.5.3
4.5.4

4.5.5

4.5.6

4.6
4.6.1
4.6.2

Counterparty
The list of counterparty types and counterparty definitions are unaltered as
compared to old HRF rules. Refer 4.6.3 (Bucket 8 Rules) for central bank
grouping types
Codes 1 or 3 14 to be used on the XML file
The code 2 is left out upon request of the PDs as it refers to the CP type BankOwn Account that has become void since January 2012
For counterparty identification process e-Sales field MG Customer Class,
Management Group Number or Mnemonic to be used. Data provided by
business (static contents) are subject to change. The logic is likely to remain
same however the values may be switched around once further clarity has
been established
Bucket 3 Bank Primary Dealer
Bucket 4 Bank Inter Dealer
Bucket 5 Bank Connected Entity
Bucket 6 Bank Customer
Bucket 7 DMO
For the Kingdom of Belgium, recognized dealers are assimilated with PDs.
Consequently all transactions between Primary Dealer (PD) and Recognized
Dealer (RD) should be reported as 3 (Bank-Primary Dealer)
RDs will be included in the list of Primary Dealers
Exception Queue :
a) If mnemonic/Act Id is blank (Technical Exception)
b) If counterparty assigned by default to bucket 14 (Business Warning) [User
can accept/ignore. Comment box to be provided (Not Mandatory)]
Country
For each individual transaction, the country of incorporation of the counterparty
should be reported using the ISO 3166-1 alpha 3 code (3 Digit Country Code)
The counterpartys location is determined by the country in which it has been
legally incorporated. For branches, the counterparty location is determined by
country of incorporation of its head office

Phase 1
Phase 1
Phase 1
Phase 1

Phase 1

Phase 2

Phase 1
Phase 1

a) The country of incorporation is available in e-Sales from the Country of

Incorporation/Citizenship field, Account General Tab.
4.6.3

b) Field to be taken from OCEAN is INC_CNTRY

Whenever the counterparty is an Asian Central Bank, the PDs can opt to report
one of the below geographical region instead of the individual country

Phase 1

Asian Central Bank identification process criteria

a) Counterparty Bucket = 8 (Central Bank and Other Public Entity)
b) Country of Inc = As per following
- Central Asia = AAA code
- East Asia = BBB code
- Far East Asia = CCC code
- West Asia = DDD code
- South Asia = EEE code
Codes AAA, BBB, CCC, DDD, EEE can be only used when the counterparty is
an Asian Central Bank
4.6.4

Exception Queue :
- If Country of Incorporation is blank or unmapped (Business Exception).
- Value in TR-Hub is editable
- New updatable value need to re-submitted by BAU

Phase 2

Page 9 of 33

4.7
4.7.1

4.7.1.1

4.7.1.2
4.7.1.3
4.7.1.4
4.7.3

5
5.1
5.2
5.3
5.4
5.4.1

5.5
5.6
5.7
5.8
5.9
5.10
5.11

System
Codes 1 14 to be used on the XML file as follows:
1 = BGC Brokers e Speed
2 = BrokerTec
3 = Bloomberg
4 = Eurex Bonds
5 = Euro MTS
6 = HDAT
7 = Local MTS (Belgium, Denmark, Finland, France, Italy and Portugal)
8 = Reuters
9 = SENAF
10 = Bondvision
11 = Tradeweb
12 = MarketAxess
13 = Other Electronic
14 = Non Electronic
In the current HRF sale to the DMO within the framework of buyback operation
before maturity has to be reported as non-electronic even when done on an etrading platform. According to the new HRF 2014 in the case the actual etrading platform must be reported
Golden source to be used is TPS SourceSystemCode field. Corresponding
OCEAN field is ORIG_SRC_SYS.
If system classification is not possible based on the provided mapping table,
the trade will fall under Bucket 14 Non Electronic (By Default) with a business
warning.
There is no differentiation between Euro MTS and Local MTS in TPS therefore
all MTS transactions to be reflected as Euro MTS
Exception Queue:
If ORIG_SRC_SYS is blank or unmapped Use default value 14. (Business
Warning) [User can accept/ignore. Comment box to be provided (Not
Mandatory)]
Phase 2 Specific Requirements
Repo for Italy Manual Excel file need to be converted into XML
Maker-Checker component applies for all exceptions Override checkbox and
Comment Box for approval process
MIS Non German Eurozone Countries
MIS Total number of trades to Debt Management Offices (DMO)
Primary market transactions are booked on following Auction Books. These
mnemonics are the counterparties on the trade
AUCEMU13, AUCEMU19, AUCEMU1A, AUCEVBEL, AUCTBILL,
AUCTCCTS, AUCTEMU2, AUCTEMU8, AUCTEMU9, AUCTITY5
MIS Total number of transactions per Product Type
MIS Total number of transactions per System
MIS Total number of transactions per CP type
MIS Total number of Secondary Transactions
MIS Monthly report to show volume between OCEAN/TPS messages and
messages reported to the DMOs
MIS rules to be user configurable
MIS Monthly German Finanzagentur Report

Phase 1

Phase - 1

Phase 1
Phase 1
Phase 1
Phase 2

Phase 2
Phase 2
Phase 2
Phase 2
Phase 2

Phase 2
Phase 2
Phase 2
Phase 2
Phase 2
Phase 2
Phase 2

Page 10 of 33

3.2 Non-Functional Requirements

Following are non-functional requirement which need to be taken during project implementation.
1. E-mail attachment size should be determined with mail server limit so that mails should not be
bounced back
o

Taken care by PMF

2. Capacity planning need to be done in advance for data pumping into TR-Hub from OCEAN. If data
set for current requirements is much smaller than OCEAN complete fixed income data set then we
should apply filter before in-hand instead of later stage.
o

There are 1.5 million average transactions / month need to pull from OCEAN hence it is decided
to pull transactions only for TPS_CASH (HRF) and IMACE (i10/FCA) source systems.

3. Data retention policy at staging area should be consistent with capacity planning. Currently we are
targeting for 10 days retention policy. If we have storage limitation then retention policy needs to be
adjusted accordingly.
o

At this point in time, no data retention policy or period has been defined. Hence, no
implementation took place with respect to this activity.

4. For business warnings, data need to be iterated into initial stage after data corrections so that it
should complete full cycle.
o

Since, data is going to share across system till ASSET layer and business warnings can be
defined differently from different business hence it is controlled at DOMAIN layer.

5. OCEAN data collection frequency should be configurable.

o

It is implemented in One-Time load and incremental mode. One-Time load will pull all
transactions of accrual month till date. Incremental load will pull and mine information as per
time period defined for given process.

6. Each process (Staging Data Extractor, Staging Data Loader, Asset Class Data Loader and Domain
Data Loader) should have capability to turn-on/turn-off on the need basis.
o

PMF is taking care of this activity.

7. Once data copied into staging area from OCEAN dump file, file should be transported to pre-defined
archival location.
o

Current implementation is taking care of file transportation for archival. Need to identify archival
location for each server (UAT/Production) before release.

8. There should be rule set level auditing to reflect any changes done at rules level which will impact
data majorly for filtering out between reportable and non-reportable data.
o

Implemented to identify failed reportable transaction with respect to given rule set.

Page 11 of 33

4 TECHNICAL DESIGN
4.1 Technical Approach
Following is the process flow of proposed system.

Phase - 1
All jobs scheduled and triggered through PMF.
1. Staging Data Extractor is ETL job which will read the OCEAN data warehouse
system and write data into flat file in certain frequency.
2. Staging Data Loader is ETL job which will read the flat file generated from Staging
Data Loader and write it into TR-Hub staging area.
3. Asset Class Data Loader program is ETL job which will load data from staging.
4. Asset Class enrichment process will look-up into reference data to get derived
values as part of asset enrichment process.
Page 12 of 33

5.

Domain Data Loader is ETL job which does following activities:

o
o
o

Read all the ASSET class data

Identify all the domain specific derived values as part of enrichment process
Apply rules to differentiate transactions as reportable or non-reportable

6. Report Generator process identifies all the latest reportable transactions excluding
last cancelled transactions as final reportable transactions.
7. XML generator process will pick up all the reportable transactions to publish in XML
report.
Phase 2

1. Generic processes across system (all technology stacks) need to be enabled for
process reconciliation, instrumentation and error logging.
2. All phase 2 specific requirements need to on-boarded on the platform (Refer
section 3.1 Functional Specification)

4.1.1 Technical Specifications

TBD

4.1.2 Modules Created / Changed / Deleted

4.1.2.1 Module - Staging Data Extractor (Created)
Synopsis
Staging Data Extractor (SDE) is data extraction program which reads the source
system data in particular frequency and writes into flat file.
Tech Stack
Talend Open Studio (TOS)
Note: Alternatively, we can enable this functionality through PMF.
Process
1. Generate entry in REPORT_AUDIT for current process with
MODULE_SHORT_CODE SDE.
2. Call HRF_REPORT.GET_TIME_WINDOW for start and end time for records to be
capture for given time window. Update audit entry (step 1) for
WINDOW_START_TIME and WINDOW_END_TIME.
3. We need to source data only for HRF and i10/FCA. Map step 2 criteria on base
query which is extracting data from source system (OCEAN) as follows:
Page 13 of 33

CREATED_TS >= START_TIME AND CREATED_TS < END_TIME

SRC_SYS IN (TPS_CASH, IMACE)
4. Dump extracted step 3 data into file as CSV format.
5. Update audit entry of step-1 with final process status and number of records
processed.
6. All columns need to be extracted from source system and corresponding
columns in CSV file is mapped under Mapping Structure section.
Mapping Structure
S.
No.
1
2
3
4
5
6
7
8

OCEAN Table Name

OCEAN Field Name

Flat File Pipe Field

FI_TRD_TRANS_DETAIL
FI_TRD_TRANS_DETAIL
FI_TRD_TRANS_DETAIL
FI_TRD_TRANS_DETAIL
FI_TRD_TRANS_DETAIL
FI_TRD_TRANS_DETAIL
FI_BOND_TRANS
FI_TRD_TRANS_MASTER

TRD_DATE
SRC_SYS
PRODUCT_TYPE
EXEC_STATUS
OCEAN_PRODUCT_ID
SIDE
TRD_QTY
ORIG_SRC_SYS

9
10
11
12
13
14
15
16
17
18
29
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

FI_TRD_TRANS_DETAIL
FI_TRD_TRANS_DETAIL
FI_TRD_TRANS_DETAIL
FI_TRD_TRANS_DETAIL
FI_TRD_TRANS_DETAIL
REF_CLIENT_ACCT
FI_TRD_TRANS_DETAIL
FI_TRD_TRANS_DETAIL
FI_TRD_TRANS_DETAIL
FI_TRD_TRANS_DETAIL
FI_TRD_TRANS_DETAIL
FI_TRD_TRANS_DETAIL
REF_CLIENT_ACCT
FI_TRD_TRANS_DETAIL
FI_TRD_TRANS_DETAIL
FI_BOND_TRANS
FI_BOND_TRANS
FI_TRD_TRANS_DETAIL
TRD_TRANS_DETAIL
FI_TRD_TRANS_DETAIL
FI_TRD_TRANS_DETAIL
FI_TRD_TRANS_DETAIL
FI_TRD_LINK
FI_TRD_TRANS_DETAIL
FI_BOND_TRANS
FI_TRD_TRANS_DETAIL

TRD_EXEC_ID
TRANS_TS
LAST_MOD_TS
TRD_EXEC_VER_NUM
TRD_PRICE
INC_CNTRY
TRD_TYPE
TRD_SUB_TYPE
SYS_FIRM_ACCT_TYPE
FII
ISIN
CUSIP
CLIENT_ACCT_ID
SYS_FIRM_ACCT_ID
BO_TRD_NUM
SYS_CLIENT_ACCT_ID
TRD_CURR
LGL_ENTY_CD
SYS_EXEC_ID
TRD_ENTRY_TS
SETL_DATE
PRNCPL_AMT
DW_FEED_TYPE_ID
EXEC_SRC_SYS
EXNG_CD
SYS_CLIENT_ACCT_TYPE

TRADE_DATE
SOURCE_SYSTEM
PRODUCT_TYPE
TRADE_EXEC_STATUS
PRODUCT_SRC_SYS_ID
BUY_SELL_FLAG
TRADE_QUANTITY
TRADE_SRC_EXEC_SYST
EM
TRADE_REF_NUM
TXN_CRTD_TS
TXN_LST_UPDT_TS
TRADE_VERSION_NUM
TRADE_PRICE
COUNTRY_OF_INC
TRADE_TYPE
TRADE_SUB_TYPE
CLIENT_ACCT_TYPE
FII
ISIN
CUSIP
CLIENT_ACCT_NO
CLIENT_ACCT_ID
BO_TRADE_NUM
BO_CLIENT_ACCT_ID
TRADE_CURRENCY
LEGAL_ENTITY_ID
SYSTEM_EXEC_ID
TRADE_ENTRY_TS
SETTLEMENT_DATE
PRINCIPAL_AMOUNT
OCEAN_FEED_TYPE_ID
EXEC_SOURCE_SYSTEM
EXCHANGE_CODE
SYS_CLIENT_ACCT_TYPE
Page 14 of 33

35
36

FI_BOND_TRANS
FI_BOND_TRANS

37
38
39
40

FI_TRD_TRANS_DETAIL
FI_TRD_TRANS_DETAIL
FI_TRD_TRANS_DETAIL
FI_TRD_TRANS_DETAIL

SETL_LOCATION
TRD_YIELD_TO_MATURIT
Y
EXEC_ACTION_TYPE
TRDR_ID
SLS_ID
STLMINST1T

41

FI_TRD_TRANS_DETAIL

STLMINST2T

42

FI_TRD_TRANS_DETAIL

STLMINST3T

43

FI_TRD_TRANS_DETAIL

STLMINST4T

44
45

FI_TRD_TRANS_DETAIL
FI_TRD_TRANS_DETAIL

CREATED_TS
ORIG_TRD_SIDE_FLAG

SETTLEMENT_LOCATION
YIELD_TO_MATURITY
MESSAGE_TYPE
TRADER_ID
SALES_PERSON_ID
SETTLEMENT_INSTRUCTI
ON_1
SETTLEMENT_INSTRUCTI
ON_2
SETTLEMENT_INSTRUCTI
ON_3
SETTLEMENT_INSTRUCTI
ON_4
CREATED_TS
ORIG_TRD_SIDE_FLAG

4.1.2.2 Module - Staging Data Loader (Created)

Synopsis
Staging Data Loader (SDL) is intermediate staging data processor which read the
file created by Staging Data Extractor program to load raw data into STAGING
table without any transformation.
In terms of HRF, Staging Data Loader reads the data file containing OCEAN Fixed
Income data and dump into STAGING Fixed Income table.
Tech Stack
Talend Open Studio (TOS)
Process
1. Generate entry in REPORT_AUDIT for current process with
MODULE_SHORT_CODE SDL.
2. Read dump file generated through Source Data Extractor program and push
into STAGING_OCEAN_FI table without any transformation.
3. Update audit entry of step-1 with final process status and number of records
processed.
4. All columns as part of CSV file and STAGING_OCEAN_FI table is mapped under
Mapping Structure section.
Mapping Structure
S.
No.

Flat File Pipe Field

STAGING_FI Field

Page 15 of 33

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45

TRADE_DATE
SOURCE_SYSTEM
PRODUCT_TYPE
TRADE_EXEC_STATUS
PRODUCT_SRC_SYS_ID
BUY_SELL_FLAG
TRADE_QUANTITY
TRADE_SRC_EXEC_SYSTEM
TRADE_REF_NUM
TXN_CRTD_TS
TXN_LST_UPDT_TS
TRADE_VERSION_NUM
TRADE_PRICE
COUNTRY_OF_INC
TRADE_TYPE
TRADE_SUB_TYPE
CLIENT_ACCT_TYPE
FII
ISIN
CUSIP
CLIENT_ACCT_NO
CLIENT_ACCT_ID
BO_TRADE_NUM
BO_CLIENT_ACCT_ID
TRADE_CURRENCY
LEGAL_ENTITY_ID
SYSTEM_EXEC_ID
TRADE_ENTRY_TS
SETTLEMENT_DATE
PRINCIPAL_AMOUNT
OCEAN_FEED_TYPE_ID
EXEC_SOURCE_SYSTEM
EXCHANGE_CODE
CLIENT_ACCT_TYPE
SETTLEMENT_LOCATION
MATURITY_DATE
MESSAGE_TYPE
TRADER_ID
SALES_PERSON_ID
SETTLEMENT_INSTRUCTION_1
SETTLEMENT_INSTRUCTION_2
SETTLEMENT_INSTRUCTION_3
SETTLEMENT_INSTRUCTION_4
CREATED_TS
ORIG_TRD_SIDE_FLAG

TRADE_DATE
SOURCE_SYSTEM
PRODUCT_TYPE
TRADE_EXEC_STATUS
PRODUCT_SRC_SYS_ID
BUY_SELL_FLAG
TRADE_QUANTITY
TRADE_SRC_EXEC_SYSTEM
TRADE_REF_NUM
TXN_CRTD_TS
TXN_LST_UPDT_TS
TRADE_VERSION_NUM
TRADE_PRICE
COUNTRY_OF_INC
TRADE_TYPE
TRADE_SUB_TYPE
CLIENT_ACCT_TYPE
FII
ISIN
CUSIP
CLIENT_ACCT_NO
CLIENT_ACCT_ID
BO_TRADE_NUM
BO_CLIENT_ACCT_ID
TRADE_CURRENCY
LEGAL_ENTITY_ID
SYSTEM_EXEC_ID
TRADE_ENTRY_TS
SETTLEMENT_DATE
PRINCIPAL_AMOUNT
OCEAN_FEED_TYPE_ID
EXEC_SOURCE_SYSTEM
EXCHANGE_CODE
CLIENT_ACCT_TYPE
SETTLEMENT_LOCATION
MATURITY_DATE
MESSAGE_TYPE
TRADER_ID
SALES_PERSON_ID
SETTLEMENT_INSTRUCTION_1
SETTLEMENT_INSTRUCTION_2
SETTLEMENT_INSTRUCTION_3
SETTLEMENT_INSTRUCTION_4
CREATED_TS
ORIG_TRD_SIDE_FLAG

Page 16 of 33

4.1.2.3 Module - Asset Class Data Loader (Created)

Synopsis
Using Talend job push recent data extracted to STAGING_OCEAN_FI table to
ASSET_FI table without any transformation.
Tech Stack
Talend Open Studio (TOS)
Process
1. Generate entry in REPORT_AUDIT for current process with
MODULE_SHORT_CODE ADL.
1. Call HRF_REPORT.GET_TIME_WINDOW for start and end time for records to be
capture for given time window. Update audit entry (step 1) for
WINDOW_START_TIME and WINDOW_END_TIME.
2. Map step 2 criteria on base query which is extracting data from source system
(STAGING_OCEAN_FI) as follows:
CREATED_TS >= START_TIME AND CREATED_TS < END_TIME
3. Read data as fetched from Step 2 and push into ASSET_FI table without any
transformation.
4. Update audit entry of step-1 with final process status and number of records
processed.
5. All columns of STAGING_OCEAN_FI and ASSET_FI is mapped under Mapping
Structure section.
Mapping Structure
S. No.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

STAGING_FI Field
TXN_UID
TRADE_DATE
SOURCE_SYSTEM
PRODUCT_TYPE
TRADE_EXEC_STATUS
PRODUCT_SRC_SYS_ID
BUY_SELL_FLAG
TRADE_QUANTITY
TRADE_SRC_EXEC_SYSTEM
TRADE_REF_NUM
TXN_CRTD_TS
TXN_LST_UPDT_TS
TRADE_VERSION_NUM
TRADE_PRICE
COUNTRY_OF_INC
TRADE_TYPE

ASSET_FI Field
TXN_UID
TRADE_DATE
SOURCE_SYSTEM
PRODUCT_TYPE
TRADE_EXEC_STATUS
PRODUCT_SRC_SYS_ID
BUY_SELL_FLAG
TRADE_QUANTITY
TRADE_SRC_EXEC_SYSTEM
TRADE_REF_NUM
TXN_CRTD_TS
TXN_LST_UPDT_TS
TRADE_VERSION_NUM
TRADE_PRICE
COUNTRY_OF_INC
TRADE_TYPE
Page 17 of 33

16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44

TRADE_SUB_TYPE
CLIENT_ACCT_TYPE
FII
ISIN
CUSIP
CLIENT_ACCT_NO
CLIENT_ACCT_ID
BO_TRADE_NUM
BO_CLIENT_ACCT_ID
TRADE_CURRENCY
LEGAL_ENTITY_ID
SYSTEM_EXEC_ID
TRADE_ENTRY_TS
SETTLEMENT_DATE
PRINCIPAL_AMOUNT
OCEAN_FEED_TYPE_ID
EXEC_SOURCE_SYSTEM
EXCHANGE_CODE
CLIENT_ACCT_TYPE
SETTLEMENT_LOCATION
MATURITY_DATE
MESSAGE_TYPE
TRADER_ID
SALES_PERSON_ID
SETTLEMENT_INSTRUCTIO
N_1
SETTLEMENT_INSTRUCTIO
N_2
SETTLEMENT_INSTRUCTIO
N_3
SETTLEMENT_INSTRUCTIO
N_4
ORIG_TRD_SIDE_FLAG

TRADE_SUB_TYPE
CLIENT_ACCT_TYPE
FII
ISIN
CUSIP
CLIENT_ACCT_NO
CLIENT_ACCT_ID
BO_TRADE_NUM
BO_CLIENT_ACCT_ID
TRADE_CURRENCY
LEGAL_ENTITY_ID
SYSTEM_EXEC_ID
TRADE_ENTRY_TS
SETTLEMENT_DATE
PRINCIPAL_AMOUNT
OCEAN_FEED_TYPE_ID
EXEC_SOURCE_SYSTEM
EXCHANGE_CODE
CLIENT_ACCT_TYPE
SETTLEMENT_LOCATION
MATURITY_DATE
MESSAGE_TYPE
TRADER_ID
SALES_PERSON_ID
STLMNT_INSTRN_1
STLMNT_INSTRN _2
STLMNT_INSTRN _3
STLMNT_INSTRN _4
ORIG_BUY_SELL_FLAG

4.1.2.4 Module Asset Data Enrichment

Synopsis
There are certain attributes of source systems whose value is either nondeterminant or non-reliable. For those attributes, system need to identify the exact
source of truth for those information and update respective attributes for accuracy
as part of enrichment process.
In terms of HRF, there are two source attributes FII and ISIN identified for
enrichment. Both need to be derived from CUSIP which is mandatory and accurate
from source systems.
Tech Stack
Page 18 of 33

Oracle PL/SQL Programming

Process
1. Generate entry in REPORT_AUDIT for current process with
MODULE_SHORT_CODE ADE.
2. Call HRF_REPORT.GET_TIME_WINDOW for start and end time for records to be
capture for given time window. Update audit entry (step 1) for
WINDOW_START_TIME and WINDOW_END_TIME.
3. Map step 2 criteria on base query which is extracting data from source system
(ASSET_FI) as follows:
CRTD_TS >= START_TIME AND CRTD_TS < END_TIME
4. Read data as fetched from Step 4 and update FII and ISIN attributes of
ASSET_FI table using reference data as follows:
S.
No.
1
2
3

Derived Column

Reference Table

Key Column

FII
ISIN
LEGAL_ENTITY_ID

ALTITB
ALTITB
LEACTROLETB

CUSIP
CUSIP
CLIENT_ACCT_ID

5. Update audit entry of step-1 with final process status and number of records
processed.
4.1.2.5 Module Domain Data Loader (Created)
Synopsis
Domain Data Loader (DDL) is responsible to transform ASSET data into DOMAIN
data by applying all rules to validate data with respect to. At the end of the
processing this loader is responsible to keep domain specific data as per definition
of domain.
In terms of HRF, after applying all the definitions, rules and data enrichment cases
for ASSET fixed income data, Domain Data Loader ensure that HRF_REPORTABLE
table is containing absolute source of truth for HRF specific reports.
Tech Stack
Talend Open Studio (TOS) + DROOLS
Process
1. Generate entry in REPORT_AUDIT for current process with
MODULE_SHORT_CODE DDL.
2. Call HRF_REPORT.GET_TIME_WINDOW for start and end time for records to be
capture for given time window. Update audit entry (step 1) for
WINDOW_START_TIME and WINDOW_END_TIME.
Page 19 of 33

3. Map step 2 criteria on base query which is extracting data from source system
(ASSET_FI) as follows:
CRTD_TS >= START_TIME AND CRTD_TS < END_TIME
4. Read data as fetched from Step 4 and retrieve other derived attributes using
reference data for HRF reportable transactions and other filtering criteria as
follows:
S.
No.
1

Derived Column

Reference Table

Key Column

LEACTROLETB

FII

FIRM_CP_LEGAL_ENTITY
_ID
COUNTRY

COUNTRY_OF_INC

3
4
5

ISSUE_COUNTRY
ISSUE_CURRENCY
CNTR_PARTY_ID

COUNTRY_MASTER_L
KP
ISTRCHETB
ISTRCHETB
CP_BUCKET_MASTER
_LKP, ACCTTB,
GRPACTROLETB

FII
FII
BO_CLIENT_ACCT_ID

5. Setup following rules under DROOLS application:

Rule
No.
1
2
3

Rule Set
1
1
1

Rule
Type
Exclusion
Inclusion
Exclusion

Exclusion

Rule
ASSET_FI.ORIG_BUY_SELL_FLAG = S
ASSET_FI.LEGAL_ENTITY_ID IN (02, 2, 2C)
ASSET_FI.TRADE_TYPE = SALES_TRADER AND
ASSET_FI.TRADE_SUB_TYPE = ALLOC
STAGING.STAGING_FI. BO_CLIENT_ACCT_ID = FICACTL
OR
STAGING.STAGING_FI. BO _CLIENT_ACCT_ID =
DROPCTL2 OR
STAGING.STAGING_FI. BO _CLIENT_ACCT_ID =
SPSTRP OR
STAGING.STAGING_FI. BO _CLIENT_ACCT_ID = ITSTRP
OR
STAGING.STAGING_FI. BO _CLIENT_ACCT_ID =
FRSTRP OR
STAGING.STAGING_FI. BO _CLIENT_ACCT_ID =
DESTRP OR
STAGING.STAGING_FI. BO _CLIENT_ACCT_ID =
ATSTRP OR
STAGING.STAGING_FI. BO _CLIENT_ACCT_ID =
NLSTRP OR
STAGING.STAGING_FI. BO _CLIENT_ACCT_ID =
BESTRP

Page 20 of 33

5
6
7

3
3
3

Inclusion
Inclusion
Inclusion

8
9
10

3
3
3

Inclusion
Inclusion
Inclusion

STAGING.STAGING_FI.TRADE_CURRENCY = EUR
TRHUB.ISPCRCYI = EUR
TRHUB. ISCNTRY = FRA OR ITA OR ITA OR ESP OR
BEL OR AUT OR FIN OR GRC OR IRL OR NLD OR
PRT
TRHUB. INSTTYPC = SEC
TRHUB.TYPC = GOVT
TRHUB.SUBTYPEC = BILL OR BOND OR GVTB OR
SRTP OR OTHB OR N/A OR NULL

6. Apply transformation logic as follows for each HRF reportable attribute.

S.
No.
1
2
3
4
5
6
7
8

ASSET_FI (Source)

HRF_REPORTABLE

TRANSFORM

TXN_UID
TRADE_DATE
CUSIP
BUY_SELL_FLAG
TRADE_QUANTITY
BO_CLIENT_ACCT_ID
TRADE_SRC_EXEC_SYSTEM
COUNTRY_OF_INC
FII

TXN_UID
TRADE_DATE
SECURITY
TXN_TYPE
QUANTITY
CNTR_PARTY_ID
SYSTEM
COUNTRY
ISSUE_COUNTRY

NO CHANGE
CASE - 1
NO CHANGE
CASE - 2
NO CHANGE
CASE 3
CASE 4
CASE 5
CASE - 6

a. CASE 1
Transform TRADE_DATE date format from YYYYMMDD to YYYY-MM-DD.
b. CASE 2
Transform the value of flag by flipping the value i.e. if field has value B (Buy)
then flip to S (Sell) and vice-versa.
c. CASE 3 Counter Party Bucket Logic
i. Populate business data (Please refer Appendix 8.1) into
CP_BUCKET_MASTER_LKP lookup table.
ii. For each BO_CLIENT_ACCT_ID of ASSET_FI table, match it with
ACCOUNT mnemonic value of reference data in ACTTB.
iii. For value retrieved at Step ii, match it with CP_BUCKET_MASTER_LKP
class (GRPMNC, ACTMNC, CLSMNC) for GROUP, CUSTOMER CLASS,
ACCOUNT mnemonic and country classification at ACTTB and
GRPACTROLETB.
iv. Step ii & iii will provide the bucket value from
CP_BUCKET_MASTER_LKP.
v. If no value will be returned by above logic then return default value
14.

Page 21 of 33

Note: Bucket 3, 4, 5, 6 classified under GRPMNC Group Mnemonic. Only

Bucket 3, 4, 6 classified for issued country and not for bucket 5.
b. CASE 4 System Bucket Logic
i. Populate business data (Please refer Appendix 8.4) into
SYSTEM_MASTER_LKP lookup table.
ii. For each TRADE_SRC_EXEC_SYSTEM of ASSET_FI table, match it with
SYSTEM_CODE of SYSTEM_MASTER_LKP table.
iii. Step ii will provide required bucket number designated for given
system.
iv. If no value will be returned by above logic then return default value
14.
c. CASE 5 Country Of In-Corporation Logic
i. Populate business data (Please refer Appendix 8.3) into
COUNTRY_MASTER_LKP lookup table. ACB flag identifies whether
country is Central Asian Bank with ACB code (AAA, BBB, CCC, DD,
EEE).
ii. For each COUNTRY_OF_INC of ASSET_FI table, match it with
ISO_3166_CODE of COUNTRY_MASTER_LKP table.
iii. Step ii will provide either ISO_3166_CODE or Central Asian Bank code.
iv. If no value will be returned by above logic then return NULL.
d. CASE 6
i. Map FII value of ASSET_FI with reference data table ISTRCHETB.
ii. Get ISRCNTRY value for ISSUE COUNTRY.
7. Run all DROOLS rule sets for each ASSET_FI transaction and if it will pass from
all rules then record transaction into HRF_REPORTABLE otherwise push record
into HRF_NON_REPORTABLE with rule set identifier.
8. Update audit entry of step-1 with final process status and number of records
processed.

4.1.2.6 Module HRF Domain Processor (Created)

Synopsis
HRF Domain Processor is data enrichment utility to identify correct record set from
the family of NEW and AMENDMENT records of given trade.

Page 22 of 33

Specific to HRF, it will read all the HRF_DOMAIN.HRF_REPORTABLE data and mark
latest transaction of given trade as reportable data for Report Generator module
which will generate final XML report for DMOs.
Tech Stack
Oracle - PL/SQL Programming
Process
1. Identify all record set of given trade on DOMAIN_HRF.HRF_REPORTABLE and
STAGING.STAGING_FI through following criteria by key TXN_UID
a. TRADE_REF_NUM
b. TRADE_VERSION_NUM
2. Mark DOMAIN_HRF.HRF_REPORTABLE.REPORT_FLAG = Y for the records which
has MAX(TRADE_VERSION_NUM) for given TRADE_REF_NUM
3. Insert record into FRAMEWORK.REPORT_AUDIT as follows for auditing purpose.
REPORT_AUDIT_ID Sequence Number
MODULE_ID FRAMEWORK.REPORT.MODULE_SHORT_CODE = HDP
REPORT_DATE Current System Date
START_RUN_TS Process Start Date with Time stamp
END_RUN_TS Process End Date with Time stamp
RECORDS_PROCESSED Total records processed by program
TOTAL_RUN_TIME Difference between START_RUN_TS and END_RUN_TS

4.1.2.7 Module Report Generator (Created)

Synopsis
Report Generator is responsible to generate report as per specifications defined in
REPORT CONFIGURATION FRAMWORK.
Specific to HRF, it will read all the HRF_DOMAIN.HRF_REPORTABLE where
REPORT_FLAG = Y and data for last month and generate XML report for
Harmonized Reporting. One XML report will be generated for each Eurozone
country (10 Countries) resulting 10 XML reports per month. Each XML file contains
the data specific to country for which trade has been executed.
Please refer Appendix 8.5 HRF Example XML Message and Appendix 8.6 HRF
Structure of XML File for more details on implementation.
Tech Stack
Java

Development Steps
<<Sadaf need to add the contents>>

Page 23 of 33

4.1.3 External Interfaces

4.2 Database Design/Layout

4.2.1 Logical Data Model

Adobe Acrobat
Document

4.2.2 Physical Data Model

Adobe Acrobat
Document

4.3 Design Considerations

4.4 Detailed Design

5 DEVELOPMENT TEST PLAN

5.1 Test Objective
5.1.1 Test Strategy
5.1.2 Entry and Exit Criteria

Page 24 of 33

5.1.3 Test Scope

5.2 Constraints on Testing

5.3 Technical Risk Identification
5.4 Test Requirements
5.4.1 Preparation
Item #
1
2
3
4
5
6

Preparation Required to conduct Development Test

Comments

5.4.2

Test Environments, Network Connections, Locations

Testing Environment

Network Connection

Test Location

5.5 DEVELOPMENT TEST Participants, Roles and Responsibilities

5.5.1 Participants and Roles
Name

Role

Department

Phone

5.6 Test Execution and Control

5.6.1 Test classes for Development Test
TEST CATEGORY NAME

Global Standard

Comments

Page
26 of 33

5.7 Development Test Scripts: Test Cases

Location of Test
Cases

Location of Test Data

Location of Test
Results

Description of How to access test cases, test

data, and test results.

Page
27 of 33

Sample Test Script

Development

Test Script

<Project Name>

WORK#
Purpose:
Prepared By:
Executed By:
Test
Case # Test Description

Date:
Date:

Test Steps

Expected Results

Actual Results

1
2
3
1
2
3
1
2
3
1
2
3
1
2
3
1
2
3
1
2
3

1
2
3
1
2
3
1
2
3
1
2
3
1
2
3
1
2
3
1
2
3

1
2
3
1
2
3
1
2
3
1
2
3
1
2
3
1
2
3
1
2
3

Pass (Y
or N)
Comments

6 RELEASE AND BACKOUT PLAN

7 GLOSSARY OF TERMS
8 APPENDICES
8.1 COUNTER PARTY Bucket Logic
Consolidate sheet provided by business after de-duplication resolution and data
clean-up. This is the final version need to be consideration.

Master CP HRF New.xls

Section 8.2 contains the initial version of same set provided by business which can
be used for future reference,

8.2 COUNTER PARTY Bucket Logic

Create following static tables in REFRENCE schema for bucketing logic of Counter
Party, Country and System attributes of HRF_REPORTABLE.
a. COUNTER PARTY Logic
Logic Type -> Bucket 1, 6, 8, 9, 10, 11, 12, 13, 14
Data File >

CP type-MG
Customer Class mapping.xls

Table > CP_TYPE_MG_CUSTOMER_CLASS

S.
No.
1
2
3
4

Attribute Name

Data Type

Data Length

MG_CUSTOMER_CLASS_ID
(PK)
MG_CUSTOMER_CLASS
DESCRIPTION
HRF_CP_TYPE

NUMBER

38

VARCHAR2
VARCHAR2
NUMBER

10
1024
2

HRF_CP_DESC

VARCHAR2

1024

Logic Type -> Bucket 3

Data File >

CP types-Primary
Dealers all.xls

Table > CP_TYPE_PRIMARY_DEALERS

S.
No.
1
2
3
4

Attribute Name

Data Type

Data Length

PRIMARY_DEALER_ID (PK)
PRIMARY_DEALER_NAME
MG_NUMBER
COUNTRY

NUMBER
VARCHAR2
NUMBER
NUMBER

38
10
38
38

Logic Type -> Bucket 4

Data File >

CP types- Bank-Inter
Dealers.xls

Table -> CP_TYPES_BANK_INTER_DEALERS

S.
No.
1
2
3
4

Attribute Name

Data Type

Data Length

PRIMARY_DEALER_ID (PK)
PRIMARY_DEALER
MG_NUMBER
COUNTRY

NUMBER
VARCHAR2
NUMBER
NUMBER

38
10
38
38

Logic Type -> Bucket 5

Data File >

CITI internal MG
Groups-FORTE.xls

Page
30 of 33

Table -> CITI_INTERNAL_MG_GROUPS

S.
No.
1
2
3

Attribute Name

Data Type

Data Length

MGMT_GROUP_ID (PK)
MGMT_GROUP_NUMBER
MGMT_GROUP_NAME

NUMBER
VARCHAR2
VARCHAR2

38
10
1024

Attribute Name

Data Type

Data Length

PRIMARY_DEALER_ID (PK)
PRIMARY_DEALER_NAME
MG_NUMBER
COUNTRY

NUMBER
VARCHAR2
NUMBER
NUMBER

38
64
38
38

Attribute Name

Data Type

Data Length

DMO_ID (PK)
BROKER
MNEMONIC
MCLE

NUMBER
VARCHAR2
VARCHAR2
VARCHAR2

38
64
64
64

Logic Type -> Bucket 6

Data File >

CP typeBank-Customer.xls

Table -> CP_TYPE_BANK_CUSTOMER

S.
No.
1
2
3
4

Logic Type -> Bucket 7

Data File >

DMOs.xls

Table -> DMO

S.
No.
1
2
3
4

8.3 COUNTRY Bucket Logic

Data File ->
Page
31 of 33

Country of
Inc-BRD.xls

Table > COUNTRY_OF_INC

S.
No.
1
2
3
4
5
6

Attribute Name

Data Type

Data Length

CNTRY_OF_INC_ID (PK)
COUNTRY_DESC
ISO_3166
E-SALER_DESC
ESALER_FRONT_END_CODE
E-SALER_BACK_END_CODE

NUMBER
VARCHAR2
VARCHAR2
NUMBER
VARCHAR2

38
1024
1024
1024
1024

VARCHAR2

1024

Data Type

Data Length

NUMBER
VARCHAR2
VARCHAR2
VARCHAR2

38
1024
1024
1024

8.4 SYSTEM Bucket Logic

Data File ->

Trading system
mapping.xls

Table -> TRADING_SYSTEM

S.
Attribute Name
No.
1
TRADING_SYS_ID (PK)
2
SRC_SYS_CODE
3
SRC_SYS_DESC
4
HRF_TRADE_SYS

8.5 HRF 2014 Regulations

New 2014 reporting

format.pdf

8.6 HRF Example XML message

Page
32 of 33

HRF_Example
XML.xml

8.7 HRF Structure of XML file

HRF Trade
Description XML.pdf

8.8 HRF- Counter Party definitions

CP definitions.doc

8.9 HRF- Country codes

HRF 2014- Country

codes.doc

8.10 GLOSSARY
DMO Dept Management Office
PD Primary Dealer
HRF- Harmonised Reporting Format
UAT- User Acceptance Testing
CP Counterparty
EFC Economic and Financial Committee
EPDA- European Primary Dealers Association
ORC Operations Regulatory Control
ORC-BAU - Operations Regulatory Control Business as Usual
FO- Front Office
BDA Belgian Debt Agency

Page
33 of 33