0% found this document useful (0 votes)
51 views17 pages

Data - Conversion Plan - 1.0 v1.2 Participants. Comp.

This document outlines the data conversion plan for migrating data from existing systems to the new Indonesia National Fund System (NFS). Key data types to be converted include sub-structural data like codes and reference data, as well as fundamental data on participants, funds, investors, and accounts. Data will be converted from KSEI, SAs, CBs, and IMs based on standardized specifications. A coordinated effort is required from all data owners to successfully convert selected data while maintaining the original data in their existing systems.

Uploaded by

Uway
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
51 views17 pages

Data - Conversion Plan - 1.0 v1.2 Participants. Comp.

This document outlines the data conversion plan for migrating data from existing systems to the new Indonesia National Fund System (NFS). Key data types to be converted include sub-structural data like codes and reference data, as well as fundamental data on participants, funds, investors, and accounts. Data will be converted from KSEI, SAs, CBs, and IMs based on standardized specifications. A coordinated effort is required from all data owners to successfully convert selected data while maintaining the original data in their existing systems.

Uploaded by

Uway
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 17

INDONESIA NEW FUND SYSTEM DEVELOPMENT

PROJECT
DATA CONVERSION PLAN

Draft Version
Document History
Version Date Type Description Author Reviewer
1.0 2016.02.26 Draft KSD Mr. Jang

The NFS Data Conversion Plan Page 2 of 17


1. Introduction

1.1 Purpose of data conversion plan


This Data Conversion Plan describes the overall conversion strategy, preparation, and specifications
for converting comprehensive and valid data from each participant’s and KSEI’s system to the New
Fund System (“S-INVEST”).

By its nature of industry-wide system like the NFS, data conversion of the NFS is not the one way
replacement of existing KSEI’s legacy systems but rather coordination and integration of market
players’ interaction between the existing platforms. Therefore, a large scale data conversion in the
traditional sense is not required, but only selected data will be needed to be converted into the NFS.

Data conversion is typically a ‘one-off’ activity prior to go-live. However, the NFS concept is to
collect data from the market participants who actually own the data and share it among other
participants. The data which are stored and managed in the participant’s system shall be considered
as the original one, and is not to be obsolete even after the NFS launches. Therefore, it is better to
name it as ‘Data Conversion’ rather than ‘Data Migration’ which assumes discarding the original
data after the conversion to the new system.

The success of the conversion strategy outlined here is contingent upon assurance that a number of
clearly identified prerequisite conditions are met before conversion activities are triggered at the
participant’s level.

1.2 Assumptions
The data conversion approach outlined in this plan is based upon the following key assumptions:

 Exhaustive participation of the data owner

Each data owner who keeps, stores, and manages fund related data that need to be converted
to the NFS shall be clearly aware of his own role and the schedule of data conversion so that
he does not fail to perform required jobs. It is essential that all of the data owners in the
market shall participate in the data conversion successfully. Otherwise, if some of the key
data owners such as SAs or CBs fail to convert the data that they own to the NFS, the
usefulness of the NFS will drop dramatically and in the worst case, it may be unable to
normally operate the NFS.

 Initial data cleansing

The clean-up of the data stored in participant’s system should be completed prior to the start
of conversion activities so that the conversion schedule outlined in this plan will not be
compromised. It is highly recommended for the data owner to perform data cleansing twice;
before the extraction of the data from the DB, and after the extraction of the data.

The NFS Data Conversion Plan Page 3 of 17


 Software development

The program to extract required data in standardized data layout from the each data owner’s
system DB shall be developed by the data owner in question.

On top of that, any necessary conversion program shall be developed by data owner
according to the specifications agreed in the NFS SRS and must be fully tested in time to
implement the approach described herein.

 Well-informed of the standardized participant codes and fund codes among data owners

For successful processing of data conversion, the standardized NFS participant codes and
funds codes need to be distributed in advance to each participant. KSEI needs to complete
collecting the participant information and the fund information, assigning new standardized
codes to each participant and fund, and distributing them to all market participants,
particularly the data owners.

The conversion procedures explained in this plan assumes that all of the data owners will use
only standardized participant codes and fund codes when they convert the data to the NFS,
which means all of the converting data that contains participant code(s) or fund code(s) shall
contain the newly assigned standardized participant code(s) or fund code(s), not the old
unstandardized codes.

1.3 Constraints
 There are a number of market players who have their own information management scheme
and DB structure. The fund related information are kept and managed in diverse ways and
formats. Therefore, KSD cannot specify the exact As-Is data table to be converted in terms of
each participant’s IT system. For this reason, the data owners need to provide such data by
themselves in accordance with a data conversion standard provided by KSD.

 Data owners shall verify the integrity of data to be converted, meet the NFS standard layout
and format, and be responsible for any problem caused during the validation checking.

 Not like other data conversions, the NFS data conversion cannot be completed in ‘one-way’
transfer of data because new standardized participant codes, fund codes, and even investor’s
fund unit accounts should be created and assigned to the existing unstandardized schemes
designed by each data owner. Data owners shall use the standardized codes and accounts which
are unfamiliar to them to convert other sets of data not losing the connection between the
standardized information and the unstandardized information which have been generated and
managed in their own ways. For this reason, following correct order of the data conversion
needs to be especially emphasized and shall be strongly enforced.

The NFS Data Conversion Plan Page 4 of 17


2. Definitions of Different Types of Data

In the context of this document, two types of data will be mentioned for conversion.

2.1 Sub-structural Data


Identified as fixed data, it describes the information about places and objects that are involved in
running the business processes. These data types tend to be created once and maintained over a long
time, and are used by a number of business activities. Examples include; Calendar information, C-
BEST securities information, Country codes, BI member codes, and Currency codes etc.

2.2 Fundamental Data


This is the key data to be prepared before the NFS operation. This type of data includes the
information to distinguish the entities who play the roles in the fund market and the assets that they
manage or own. Examples include; participant’s information, fund information, KYC, and Investor
unit account etc.

Note that the transaction data which describes each investor’s transaction detail is out of question in
data conversion. Transaction data will be inputted through normal operation of the NFS since its
launch.

3. Scope of Data Conversion

Hundreds of different types of fund related data are being generated, kept, and handled by many
market players in various formats and layouts. Among those data, only selected data will be included
in the scope of data conversion for the NFS. Such data has been discussed and decided with the
working group and KSEI.

All data sets that need to be converted to the NFS are shown in [Figure 1].

The NFS Data Conversion Plan Page 5 of 17


Figure 1. Scope of Data Conversion

3.1 Data to be converted from KSEI’s existing system


KSEI is the key player in the data conversion for the NFS. It is the sole provider of the sub-structural
data and the participant information which is one of the key fundamental data. The list of the data
that need to be converted from KSEI’s existing system is like following.

 C-BEST Securities Information

 Participant Information (BR, IM, CB, SA) including the administrator information

 Portfolio Profile Data (e-monitoring)

 CB Internal Code and Standard Code Mapping Table

 Non C-BEST Securities Information

 List of Country Codes (ISO Standard)

 BI Member Codes (C-BEST)

 C-BEST NextG’s List of State / Province

 C-BEST NextG’s List of Cities

 List of Currency Codes (ISO Standard)

 Bank Code for Placement Bank Code Management

 ARIA City Codes (ARIA)

The NFS Data Conversion Plan Page 6 of 17


3.2 Data to be converted from SA
SA is the market participant who keeps and handles the fund investor information, investor-owned
funds records and the transaction history. The list of data that need to be converted from SAs is like
following.

 Individual Investor KYC data

 Institutional Investor KYC data

 Investor Unit Account Information (Unstandardized) including the key value that connects to
the investor accounts managed by CBs

 Redemption Payment Accounts

 Selling Agents’ Fund List

3.3 Data to be converted from CB


CB is the market participant who actually holds the fund assets and performs the book-keeping for
each fund and investor. The list of data that need to be converted from CBs is like following.

 Fund Information (minta ke BK sesuai dgn new Fund code for S-INVEST)

 Placement Bank Code

 Bank Charge Information (please refer to SRS p.14)

 Investor Fund Unit Account Balance

 Fund Outstanding Unit Balance

3.4 Data to be converted from IM


IM is the market participant who makes the decision with regard to the management of fund
including investment, liquidation, distributed income and so forth. The list of data that need to be
converted from IMs is like following.

 Distributed Income

4. Data Conversion Strategy

4.1 Conversion Principle

The NFS Data Conversion Plan Page 7 of 17


The NFS is the first of its kind in the Indonesian fund market. As this system is built to improve the
transparency of and the access to the fund information in the market, all market participants are
required to use standard formats. Therefore, conventional mapping rules which connect every As-Is
data to To-Be data cannot be applied for the NFS, rather the new standard for the NFS will be
provided to market participants in advance to conversion so that each participant can use the standard
to convert its own data by themselves in the format that can be loaded directly into the NFS DB. The
standard data layouts of the To-Be data sets will be provided separately.

4.2 Conversion Approach


 Data conversion needs to be repeated at each test level to improve reliability of the conversion
result.

 Reports to be submitted to OJK are not included in the data conversion.

 When converting the data, data owners shall not amend or modify content of the original data
at its own discretion for any reason. If though such data needs to be classified as confidential,
KSEI and KSD will safely manage the data for each participant as specified in the NFS SRS.

 If the volume of data to be converted from a data owner is relatively low or is of poor quality,
manual keying-in of the data using the NFS screen can enable to validate the data at the time of
entry.

 Right before the NFS launches, in order to facilitate stable opening of the system, participants
need to secure enough time to check and verify the converted data to improve the integrity of it.
To support that purpose, not like other data, a group of data will be converted a week before
the NFS opening date and amendment to the data will be done manually. Such data shall
include all of the data to be converted from KSEI, Fund information (from CB), and Selling
Agents’ Fund List (from SA).

4.3 Roles and Responsibilities


Successful conversion of data into the NFS requires a significant and diverse input from many
different sources. Data owners should completely understand the IT systems and the DB structures
from which the data will be extracted. In addition, data owners need to completely understand the
business processes that the extracted data is supporting. For that reason, the each item of the target
data has to be converted by the data owner to ensure the completeness and the integrity of the
converted data for the NFS.

 KSD will present data standards for the NFS.

 Each data owner shall provide converted data to KSEI in accordance with the data standards
following the schedule defined in 6. Data Conversion Schedule.

The NFS Data Conversion Plan Page 8 of 17


 Each data owner shall bear overall responsibility for ensuring “fit for use” of the converted
data. To guarantee that, data owner shall perform data cleansing before it delivers the converted
data file to KSEI.

 KSEI shall check the validation of the converted data submitted by the data owner, and ensure
the integrity of data with the data owner.

 KSD will load the converted data to the NFS after validation check by KSEI and data owner.

4.4 Conversion Process

1. Identify

Data owners need to check the detail of the data to be converted and the standardized layout
of it. Once the data owner has identified the target data, he needs to check the current
locations of data in his own IT system as well as the format of the data before mapping and
setting conversion rules.
2. Extract

Data shall be extracted from the data owner’s system by any method defined and developed
by himself. If the extracted data does not have same format with the standard, data owner
has to transform the data to meet the standard.
3. Cleansing

Target data must be completely cleansed by each data owner prior to delivery to the KSEI in
order to ensure consistency and accuracy. As a general approach, data can be cleansed on
each data owner’s DB before extraction, however, there may be circumstances where this is
not the best method and the data can be cleansed after it has been extracted. In any case, it
must be guaranteed that cleansing should be done at least once before it is submitted to the
KSEI. The data cleansing cycle includes the following steps:

 Elimination obsolete records.

The NFS Data Conversion Plan Page 9 of 17


 Removal of duplicative records.

 Correcting inaccurate records.

 Correcting incomplete records.

 Mapping the standardized codes or accounts to the unstandardized data

4. Delivery

After cleansing, each data owner shall provide the extracted data to the KSEI before noon on
the first day (begin date) of the predefined data conversion schedule except the fund unit
balance which shall be delivered by CBs on the next day.

Data shall be delivered in the format of .txt file using the vertical line (‘|’) to separate data
factors in the file. The standard to name the data file is ‘Data ID_Participant Code_Extracted
Date.txt’. Data ID is presented in the Data Conversion Rule which will be provided by KSD.

For example, if an SA whose standardized participant code is SA101 delivers the Individual
Investor KYC Data extracted on Feb 1 2016, the data file should be named as
‘0401_SA101_20160201.txt’.

5. Validation Check

Once the data file is delivered to KSEI, KSEI shall perform validation check with the
assistance of KSD using the appropriate program. If it fails to pass the validation check
process, the data shall be returned to the data owner and he has to cleanse the data again.

6. Loading

KSEI shall hand over the data file that passed the validation check and KSD will load it to
the NFS DB.

5. Data Conversion Order

As indicated previously, data conversion for the NFS is not a simple process since it requires
bilateral transfer of the data. On top of that, throughout the whole process, data owners need to be
very careful not to lose the connection between the standardized codes and the matched information
that are managed in unstandardized way by themselves.

Data shall be converted and loaded to the NFS in right order as some of the data work as the
prerequisite for other data. Therefore, this order shall be strictly obeyed. Figure 2 to Figure 11 are
explaining the exact order of the data conversion.

5.1 Independent Sub-structural Data


The NFS Data Conversion Plan Page 10 of 17
Figure 2 Conversion of the independent Sub-structural data

C-BEST securities information and Calendar information are the completely independent sub-
structural data. Therefore, these data can be converted to the NFS at any time without considering the
relation to other data sets or order to load. To simplify the conversion order, they will be loaded to
the NFS first. The owner of these data is KSEI and the conversion shall be executed by KSD with the
assistance of KSEI.

5.2 Sub-structural Data (Meta Codes)


Seven sub-structural data which include List of Country Codes (ISO Standard), BI Member Codes,
C-BEST NextG’s List of State / Province, C-BEST NextG’s List of Cities, List of Currency Codes
(ISO Standard), Bank Codes for Placement Bank Code Management, and ARIA city codes shall be
converted prior to loading other data since they will be used for registering the participants or the
investors. The owner of these data is KSEI and the conversion shall be executed by KSD with the
assistance of KSEI.

The NFS Data Conversion Plan Page 11 of 17


Figure 3 Conversion of Sub-structural data

5.3 Participant Information including administrator information


To enable the participants to access to the NFS, the participant information with the administrator
information of each participant shall be loaded next. KSEI needs to collect the relevant data from
each participant to prepare the complete set of the participant information before the conversion. The
participant codes in this data file should contain the standardized participant codes. The conversion
shall be executed by KSD with the assistance of KSEI.

Figure 4 Conversion of Participant Information

The NFS Data Conversion Plan Page 12 of 17


5.4 Fund Information

Figure 5 Conversion of Fund Information

Next Step is to convert the fund information. Data owners of the fund information are CBs and CBs
have to transfer the fund information which contains the standardized fund codes and participant
codes to KSEI. Each CB shall extract and cleanse the information of all funds that he takes custody
of. The fund information shall be submitted to KSEI to pass the validation check and KSD will load
it to the NFS DB.

5.5 Selling Agent’s Fund List


After the conversion of fund information has been completed, each SA shall convert the list of funds
that he sells. The participant codes and the fund codes in this data shall be the standardized ones. The
Selling Agent’s Fund list shall be submitted to KSEI to pass the validation check and KSD will load
it to the NFS DB.

The NFS Data Conversion Plan Page 13 of 17


Figure 6 Conversion of Selling Agent’s Fund List

5.6 Individual/Institutional Investor KYC Information

Figure 7 Conversion of Individual/Institutional Investor KYC Information

Next step is to convert the investor information. This information is created and managed by the SAs,
so SA shall be the entity to perform data conversion. The participant codes in this data shall be the
standardized codes. The individual/institutional KYC information shall be submitted to KSEI to pass
the validation check and KSD will load it to the NFS DB.

The NFS Data Conversion Plan Page 14 of 17


5.7 Investor Fund Unit Account and Redemption Payment Account

Figure 8 Conversion of Investor Fund Unit Account

Once the KYC data has been loaded to the NFS, the standardized fund unit account for each investor
must be created. To support and validate each investor’s current account holding situation, SA needs
to transfer the detail of each investor’s fund unit account information including registered redemption
payment accounts. When converting the investor fund unit account data, the key value that specifies
a certain account that CB can allocate a particular fund balance for the investor must be included in
the data. This is quite important because, if an investor has multiple accounts, CB cannot indicate to
which account the fund balance should be allocated. The standardized participant codes and fund
codes must be used in the data file which is to be transferred from the SA to KSEI. The investor
fund unit account information shall be submitted to KSEI to pass the validation check and KSD will
load it to the NFS DB.

5.8 Distribution of Standardized Investor Fund Unit Account


KSD will produce standardized investor fund unit accounts using the investor fund unit account data
transferred from the SA as described in 5.7. The standardized fund unit account will be generated and
assigned to every single account of an investor. Therefore, if an investor currently has three accounts,
three standardized accounts will be created and assigned for the investor. The standardized investor
fund unit account data will be provided in a data file format (.txt) to both SAs and CBs. In addition,
SAs and CBs can download it from the NFS directly.

The NFS Data Conversion Plan Page 15 of 17


Figure 9 Distribution of Standardized Investor Fund Unit Account

5.9 Fund Unit Balance

Figure 10 Conversion of Fund Unit Balance

As the standardized investor fund unit accounts have been generated through the process of 5.8, the
next step is to allocate the actual fund unit balance to each account of the investors. Data owner who
keeps the records of fund balance is CB, so CBs shall perform the conversion of such data. Two data
sets shall be converted by CB; Investor fund unit account balance and Fund outstanding unit balance.
The NFS Data Conversion Plan Page 16 of 17
The standardized participant codes, fund codes and investor fund unit account should be used in the
data file which is to be transferred from the CB to KSEI. In this process, CBs shall pay great
attention not to be confused to have allocated wrong fund units and/or to wrong account of an
investor. For that purpose, CB shall follow the key value provided by SA as described in 5.7 not to
lose the connection between the standardized account and the old one. The investor fund unit account
balance and the fund outstanding unit balance information shall be submitted to KSEI to pass the
validation check and KSD will load it to the NFS DB.

5.10 Conversion of the rest data

Figure 11 Conversion of the rest data

After all fundamental data have been successfully converted to the NFS, other data within the scope
of data conversion shall be converted. This includes Portfolio Profile Data (e-monitoring), CB
Internal Code and Standard Code Mapping Table, Non C-BEST Securities which are to be converted
from KSEI’s system, Distributed Income Data from IMs, and Placement Bank Code and Bank
Charge Information from CBs. Any participant codes, fund codes, or investor fund unit accounts
contained in the data file transferred to KSEI should be standardized ones and KSD will load the data
file to the NFS DB when it passes the validation check by KSEI.

The NFS Data Conversion Plan Page 17 of 17

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy