using the cs -drms 2000+ in settlement of foreign...

USING THE CS-DRMS 2000+ IN SETTLEMENT OF FOREIGN

PAYMENT IN A DEBT MANAGEMENT OFFICE

by

George M Kariuki

A Paper presented to the MEFMI Secretariat

in partial fulfillment of the Fellows Development Programme

May 2007

IT SUPPORT FOR CS-DRMS 2000+

ii

TABLE OF CONTENTS PAGE NO.

LIST OF TABLES ...........................................................................................III LIST OF CHARTS ..........................................................................................III LIST OF ANNEXES ........................................................................................III LIST OF ACRONYMS AND ABBREVIATIONS ................................................ IV ACKNOWLEDGEMENT..................................................................................V PREFACE .................................................................................................... VII EXECUTIVE SUMMARY ............................................................................. VIII CHAPTER ONE ............................................................................................. 1 1. INTRODUCTION ........................................................................................ 1

1.1 RESEARCH PROBLEM .........................................................................................................1 1.2 CONSTRAINTS OF THE CURRENT FOREIGN DEBT PAYMENT PROCESS ...................2 1.3 OBJECTIVE OF THE STUDY .................................................................................................5 1.4 PROJECT APPROACH AND METHODOLOGY ....................................................................5

CHAPTER TWO............................................................................................. 7 2. CURRENT STATUS ................................................................................... 7

2.1 THE BACK OFFICE ...............................................................................................................7 2.2 REVIEW OF THE EXISTING MANUAL PAYMENT ADVICES PREPARATION PROCESS.7

CHAPTER THREE ........................................................................................12 3. PROPOSED AUTOMATE D PUBLIC DEBT PAYMENTS SYSTEM DESIGN .12

3.1 OBJECTIVES OF THE NEW SYSTEM................................................................................12 3.2 SPECIFIC OBJECTIVES ......................................................................................................12 3.3 SYSTEM REQUIREMENTS .................................................................................................13 3.4 DATA REQUIREMENT.........................................................................................................14 3.5 DATA-SETS OF THE PAPS SYSTEM..............................................................................15 3.6 MAPPING OF DATA ELEMENTS TO PAPS ENTITIES. ....................................................15

CHAPTER FOUR ..........................................................................................24 4. USING CS -DRMS FOR EXTERNAL LOANS PAYMENT. .............................24 CHAPTER FIVE ............................................................................................26 5. CONCLUSION ..........................................................................................26 REFERENCES..............................................................................................27


iii

LIST OF TABLES TABLE 1: SYSTEM REQUIREMENTS..............................................................................13 TABLE 2: DATA SETS...........................................................................................................15 TABLE 3: PADATA TABLE .................................................................................................15 TABLE 4: FOREIGN KEYS IN PADATA TABLE...........................................................16 TABLE 5: DEMAND TABLE................................................................................................17 TABLE 6: FOREIGN KEYS FOR DEMAND TABLE......................................................17 TABLE 7: BANK TABLE.......................................................................................................18 TABLE 8: FOREIGN KEYS FOR BANK TABLE ............................................................18 TABLE 9: PAYMENT TABLE..............................................................................................18 TABLE 10: FOREIGN KEYS FOR PAYMENT TABLE .................................................19 TABLE 11: LOANDATA TABLE ........................................................................................19 TABLE 12: FOREIGN KEYS FOR LOANDATA .............................................................19 TABLE 13: PAYTYPE TABLE.............................................................................................20 TABLE 14: LENDER TABLE ...............................................................................................20 TABLE 15: FOREIGN KEYS FOR LENDER TABLE .....................................................20 TABLE 16: CURRENCY TABLE.........................................................................................21 TABLE 17: FOREIGN KEYS FOR CURRENCY TABLE...............................................21 TABLE 18: DEFAULTS TABLE ..........................................................................................21 TABLE 19: PAPSUSER TABLE...........................................................................................22

LIST OF CHARTS

CHART 1: THE PA PREPARATION PROCESS...............................................................11 CHART 2: SCHEMATIC VIEW OF THE TABLES..........................................................23

LIST OF ANNEXES

ANNEX 1: BLANK PA FORM ..............................................................................................28 ANNEX 2: ELECTRONICALLY FILLED PA FORM .....................................................29


iv

LIST OF ACRONYMS AND ABBREVIATIONS AC Files Accounts File

CBK: Central Bank of Kenya

ComSec Commonwealth Secretariat

CS-DRMS: Commonwealth Secretariat- Debt Recording and Management

System

DMD Debt Management Department

DMFAS Debt Management and Financial Analysis System

DRS Data Recording Section

EPRMD External Payments and Reserve Management Department

IBAN International Bank Account Number

ICT: Information Communication Technology

LAN Local Area Network

MoF Ministry of Finance

PA Payment Advice

PAPS Payment Advice Printing System

PDS Public Debt Section

SPAC Senior Principal Account Controller

SWIFT Society for Worldwide Interbank Financial Telecommunications

UNCTAD United Nations Conference on Trade and Development


v

ACKNOWLEDGEMENT This paper is about enhancing foreign debt settlement using the ComSec’s CS-

DRMS 2000+ software and reflects what I have been up to in the last couple of

years. It all began in 2004 when the Ministry of Finance, Kenya nominated me to

attend a Fellows Selection interview conducted by the MEFMI in Harare,

Zimbabwe. After the highly contested interview, MEFMI selected me to be a

Candidate Fellow. Ever since I have interacted with many people who supported

me in one way or the other in my fellowship programme. Since it is impossible to

thank them all, I will therefore only mention those without whom this study could

never have been accomplished.

This work would not have been possible without the guidance, support and

encouragement of MEFMI staff, in particular Anna Msutze whose guidance was

very valuable. Some MEFMI staff also gave vital technical support and would be

failing if I do not recognize them, Jason Kamweru and Leslie Mkandawire.

I am deeply grateful to my mentor, Vikas Pandey, Systems developer Officer,

ComSec whose help, suggestions and encouragement helped me in all the time

of research for and writing this paper.

Other ComSec’s staff that I would also wish to thank for their support and

encouragement include Jose Maurel, Mac Banda and Carilus Odumbe.

I also wish to thank my supervisor, Haron Sirima, Deputy Director, Debt

Management Department (MoF Kenya) who always gave me confidence and

support challenging me daily to look beyond for the opportunities ahead of

successive completion of the programme.


vi

My sincere thanks to my colleagues, Andrew Mwariri and Andrew Njogu both

Information Communication Technology officers, for their extensive discussions

around my work.

Special thanks to the Debt Management Department staff for their support.

Finally, I owe loving thanks to my wife Emily, my sons Victor and Innocent.

Without their encouragement and understanding it would have been impossible

for me to finish this work.


vii

PREFACE Accurate and timely settlement of foreign payments remains a major challenge

for many developing nations. This is partly due to the manual processes involved

in preparing the payments. Another factor that affects the payment processes

includes poor communication channels between the creditors and the borrowers.

Bills from the creditors may take a long time before they are received by the

settlement sections. Unreliable databases also contribute to poor settlements of

foreign debts.

Two of the most widely used systems for debt recording are the Commonwealth

Secretariat Debt Recording and Management System (CS-DRMS) 2000+

developed by the Commonwealth Secretariat (ComSec) and the Debt

Management and Financial Analysis System (DMFAS) developed by the United

Nations Conference on Trade and Development (UNCTAD). These two systems

so far, however, do not address the issue of settlement of foreign payments.

This paper is an attempt to demonstrate how the CS-DRMS 2000+ can be

enhanced to assist in settlement of foreign debt payments. This would be a very

cost effective venture since it would use an already established platform. Most of

the data used for foreign settlement of loans is already recorded in the system

which means that very little extra effort will be required.

This added functionality would, however, not make the CS-DRMS 2000+ a

Financial Management System. It would only serve as an interface between the

CS-DRMS 2000+ and other financial systems.


viii

EXECUTIVE SUMMARY

The CS-DRMS 2000+ is a software programme designed by the Commonwealth

Secretariat to provide borrowers with a comprehensive information management

system for the effective recording, administration and analysis of debt. This

robust system has several modules namely the External Debt, the Domestic

Debt, Disbursements, Reports and Auctioning modules among others. The

External Debt module, which this paper focuses on, is used as a repository of

both public and private sector debt.

Effective debt management however goes beyond recording and analyzing debt

portfolios. Timely settlement of debts is also a key to good debt management.

Late payments attract huge penalties and should be avoided as much as

possible since penalties are not usually budgeted for. In some cases paying in

advance is also penalized. This paper demonstrates how the CS-DRMS 2000+

software can be used to enhance efficient and timely payment of external debts.

A study of the CS-DRMS schema was undertaken. This was done by reviewing

the available system’s manuals that are packaged together with the CS-DRMS

software. The system comes with five installable manuals namely the

Administrator’s, External Debt, Domestic Debt, Management Tools and Reports

Manuals. The Administrator’s manual is rich in the CS-DRMS schema details.

The study of the current debt service payment system revealed that the process

of debt serving starts when a notification of the payment (Demand Bill) is

received by the Director, Debt Management Department (DMD). There are

several notices from creditors namely: demand notes, new disbursements, loan

balances, variable interest rates advice, acknowledgements of payments and

repayment schedule. The study focused on the contents of the demand notes


ix

and the payment process. The current payment process takes not less than five

hours from receipt of the demand note to the time it is ready for signature. The

designed tool in this study is estimated to take less than fifteen minutes.

Whereas in the current system, anyone with access to the payment advices can

type in payment instructions, the proposed tool ensures that only authorized

personnel have access to the tool. It has been revealed in this study that there is

reduction in the typo errors.

Following the review of the current tool (demand note) and processes the

following data elements of PAPS are designed in this study: PAData (The actual

details of the PA, including number and date), Demand (Bill details, including the

actual part-payments), LoanData (Loan details as recorded in the agreement),

PayTypes (The various types of payments, including penalties), Payments (All

payments that have been made to creditors), Lenders (Creditors details –

updated periodically), Currencies (Currencies used), Banks (Bank details,

including IBAN and SWIFT), Defaults (CBK authorized PA signatories) and

PAPSUsers (System User access rights and privileges in the system).

The study further maps the data elements to the detailed PAPS entities. The

output of the study is the electronic draft demand notice with all information

extracted from the CS-DRMS and additional information extracted from the

current demand note but not captured in the CS-DRMS.

This facilitates timely settlement and ensures security of payments.


1

CHAPTER ONE

1. Introduction 1.1 Research Problem

Debt portfolios are usually the largest financial portfolios in many countries. Poorly

managed portfolios would lead nations to experience economic and financial

shocks which may result to economic crises. Debt portfolios, therefore, calls for

prudent management to avert any economic crisis. The first step in debt

management is to have an accurate inventory of all public debt. The

Commonwealth Secretariat (ComSec) is amongst institutions that have come up

with a computer based systems to help manage debt portfolios. ComSec’s system

is called the Commonwealth Secretariat Debt Recording and Management System

(CS-DRMS) 2000+. The current version of the software is CS-DRMS 2000+

VERSION 1.2. Besides the occasional upgrades, ComSec usually releases a new

version of the software every year. The need of new releases arises from the

dynamism of the debt management practices and also issues raised by users.

The CS-DRMS 2000+ is a software programme designed by the Commonwealth

Secretariat to provide borrowers with a comprehensive information management

system for the effective recording, administration and analysis of debt.1 This robust

system has several modules namely the External Debt, the Domestic Debt,

Disbursements, Reports and Auctioning modules among others. The External

Debt module, which this paper focuses on, is used as a repository of both public

and private sector debt.

Effective debt management however goes beyond recording and analyzing debt

portfolios. Timely settlement of debts is also a key to good debt management. Late

payments attract huge penalties and should be avoided as much as possible since

1 External Debt reference Manual - ComSec


2

penalties are not usually budgeted for. In some cases paying in advance is also

penalized. This paper will demonstrate how the CS-DRMS 2000+ software can be

used to enhance efficient and timely payment of external debts.

In this paper Kenya is used as case study and demonstrates how the system can

further be utilized to assist in the foreign debt settlement.

The payment process is initiated by the Ministry of Finance upon receiving

demand bills from creditors. In some cases schedules are used. Payment Advices

(or Payment Vouchers) are forms of cheques prepared by the Ministry of Finance.

They contain the payment instructions, that is, the Creditor being paid, the

Creditor’s bank details, the payment type and amount among other details. Signed

Payment Advices are then sent to the Central Bank of Kenya (CBK) for the

payment to be effected as per the instructions in the Payment Advice.

1.2 Constraints of the Current Foreign Debt Payment Process

A review of the current debt payment process revealed that the process is

characterized by delays, which at times lead to penalties that would otherwise

have been avoided if such payments were made on time. Double payments of

loans and typographical errors have also been reported. The Payment Advice

forms are typed using typewriters which at times breakdown throwing the whole

process into disarray.

Upon receipt of a demand notice in the Back Office, a Payment Advice is

prepared, a process that takes up to two days before eventually submitting it to

Central Bank for the payment to be effected. Head of Public Debt Section marks

the demand notice to one of the officers to prepare the payments advice. Upon

receiving the Payment Advice, the officer gets the file for the loan from the registry.

At times the file may be in use by another officer in another debt section and this

occasions delay in the payment preparation process. Incidences have occurred

where a file goes missing for more than a week. When the officer gets file, a draft


3

Payment Advice is prepared. After authorization by the head of the section the

draft is ready for typing, a stage that has remained a bottleneck to the process.

The Payment Advices are then taken for coding, a unique code that is assigned

as a security measure, the CBK understands the code. Coding is then followed by

signing of the Payment Advice. Three signatories, including the Permanent

Secretary to the Treasury are authorized to sign the Payment Advice. They duly

signed Payment Advices are then taken to the CBK for payment.

There have been instances where printed PA forms have been cancelled, leading

to repeated preparation processes.

It should be noted that there is a lot of repetition that happens over time in the

processing of the PA. Most of the times the information that changes is only the

type of payment, the payment amount and due dates. Details of creditor or Banks,

for example, do rarely change. This then means that most of the work the officers

do over time is quite repetitive.

The bills, at times, have a language that the officers in the Back Office, with their

limited banking knowledge, are unable to accurately interpret. This has resulted in

data being keyed in the wrong fields of the Payment Advice forms. A case in point

is a situation where a creditor happens to be a banking institution. In such cases

the creditor, just like the payment receiving bank, has a SWIFT code. You’ll find

then that both the creditor’s and bank’s SWIFT codes are typed in the receiving

bank’s field .

Most of the problems and constraints outlined above can be explained within the

PIECES framework for classification of problems, opportunities, and directives,

developed by James Wetherbe (1984, p. 114). The acronym PIECES is derived

from the first letter of each of the six framework categories as outlined below:

1. The need to improve performance;

2. The need to improve or control information (or data);


4

3. The need to improve economics or control costs;

4. The need to improve control and security;

5. The need to improve efficiency of people and machines; and

6. The need to improve services to employees, managers, partners, etc.


5

1.3 Objective of the Study

This study seeks to demonstrate how the CS-DRMS 2000+ software can be

further enhanced to facilitate foreign debt repayments. Currently the system is

widely used in recording and analyzing debts. Since most of the details used in

settlement of foreign debt is already recorded in the CS-DRMS database, only

very little upgrade would be made to the system to achieve this objective.

Currently the preparation of Payment Advice forms for the foreign debts settlement

is done at the Back Office using manual systems. The use of a computerized

system for settlement of foreign debt payments, therefore, would lead to the

automation of the Back Office processes. This would be a step towards proper

control of printing of the Payment Advice forms, avoid risk of loss of information

and would enhance productivity in the Back Office.

For the purpose of this paper the Payment Advice forms printing system will be

referred to as the PAPS.

1.4 Project Approach and Methodology

The initial work of computerizing the Payment Advice form preparation process

began with consultations with key stakeholders. These included personnel from

the Debt Management Department (DMD) and the External Payments and

Reserve Management Department (EPRMD) of the Central Bank of Kenya (CBK).

The former being responsible for settlement of foreign debt payments and the

latter responsible for the transfer of the payments to the creditor’s foreign

accounts.

A preliminary study of the current Debt Management Department’s (Kenya) Back

Office operations was undertaken. The main purpose of the study was to identify

the problems of the current system, limitations, and constraints associated with the

foreign debt payment process.


6

Several meetings were conducted with members drawn from Debt Management

Department, Back Office section and the Kenya’s Central Bank’s EPRMD. The

meetings aimed at understanding the business operations of the PA form

preparation process.

Further a review of the CS-DRMS schema was also undertaken. This was done by

studying the available system’s manuals that are shipped together with the CS-

DRMS software. The system comes with five installable manuals namely the

Administrators, External Debt, Domestic Debt, Management Tools and Reports

Manuals. The Administrator’s manual is rich in the CS-DRMS schema details.

The following are the steps undertaken in developing the tool:

STEP 1: The software concept. The existing manual system was found to be too

slow. A need to minimize the time taken for preparing the Payment Advice forms,

increase productivity, quality and efficiency of in the back office was seen as

something that needed to be addressed. There was a need to use the Information

Technology to help the Back Office achieve its strategic objectives.

STEP 2: Requirements Analysis. The new system requirements are defined. The

data structures (field names, data types and lengths) were identified.

STEP 3: Architectural design. The database and the user interface were done

using Clarion 6 Programming tool. The control procedures and access privileges

were also designed. The users were further trained on the system.

STEP 4: The system is put into use. The developed tool was put use and it proved

very successive. PA forms were printed and a sample is given in Annex 2 below.


7

CHAPTER TWO

2. Current Status 2.1 The Back Office

The Kenya’s Ministry of Finance (MOF) is the arm of Government charged with the

responsibility of mobilizing domestic and external funds for financing Government

budgetary requirements. The funds are in form of loans and grants.

The responsibility of loan repayment rests with the Debt Management Department

(DMD) whose functions, among others, include formulation of Public Debt

Management policies and strategies; maintenance of a comprehensive inventory

of loans together with forecast of debt service; and effecting debt service

payments accurately and on timely basis. DMD is divided into Front, Middle and

Back Offices

The Back Office is responsible for processing all foreign payments upon receipt of

demand notices, also called demand bills, from creditors. This includes typing of

the Payment Advice forms, forwarding them for signatures to authorized

signatories and eventually submitting them to the Central Back for the payments to

be effected.

2.2 Review of the existing manual Payment Advices Preparation Process This section reviews the existing Payment Advices preparation process in the

Back Office of the Debt Department. The main source of information is copies of

all the demand bills, Payment Advice forms, and draft Payment Advice forms used

in the current system. Work procedure manuals and written instruction guidelines

are other useful data sources. These documents were very useful for one to

understand the technical terms used in the back office.


8

The writer spent time observing what role each officer was playing in the back

office. This was useful as it provided first hand information on issues relating to the

Payment Advices preparation process.

Additional information was gathered through holding of meetings with the users to

further clarify the issues raised. These users included those from the Front and

Back Offices in DMD, and also those from the Central Bank of Kenya who deal

directly with foreign payments.

(i) The process of debt serving starts when a notification of the payment (Demand

Bill) is received by the Director, Debt Management Department (DMD). The

following are the forms of notifications from creditors: -

a) Demand notes

b) New disbursements

c) Loan Balances

d) Variable Interest rates advice

e) Acknowledgements of payments

f) Repayment Schedule.

In absence of demand note from a creditor, the Head Public Debt Section (PDS), a

section in the Back Office, will forward the relevant accounts file (called the AC

file) to the Director, DMD so that the latter may authorize the payments of amounts

falling due as per the schedules in the files. AC files are maintained by the Back

Office and contain copies of loan agreements, correspondences between the

Government and the Creditors, including copies of past Payment Advices that

have been processed.

(ii) Upon receipt of the payment notification, the Director, DMD forwards them to

Head, Debt Recording Section (DRS) for necessary action by the relevant officers

as follows: -


9

a) Demand Notices

I. Verify contents of the demand notices against the Commonwealth

Secretariat Debt Recording and Management System (CS-DRMS)

database. The amounts demanded by the creditor must be forecasted in

the system. Should they be penalties, the system should also show some

past underpayments or late payments.

II. Record relevant data on the Demand Note in the CS-DRMS debt database

as a bill.

III. Indicate the relevant AC file number and Loan Key number on the Demand

Note. This will assist the Public Debt Section quickly identify which

accounts file (AC file) to use.

IV. Forward the Demand Note to the Head, Public Debt Section (PDS). The

latter will initiate the payment preparation process.

V. In absence of Demand Notes, the Director DMD will authorize initiation of

payments to the creditor on the basis of records available pending receipt of

creditor demand notes.

(b) Notification of new interest rate applicable

i. Head, DRS will update the CS-DRMS debt data base with the new interest

rate applicable

ii. Indicate the relevant AC file number and Loan Key number on the

notification of interest rate applicable

iii. Forward the notification of the new interest rate applicable to Head, Public

Debt Section (PDS) to note and pass for filing in the relevant AC file

(c) Preparation of Payment Advices (PAs)

i Head, PDS checks for approval to process the Demand Notes from the

Director, DMD and Head, DRS or relevant officer from DRS

ii Head, PDS instructs the relevant officers to draft the PAs

iii The Draft PAs are examined


10

iv PAs drafts are typed and rechecked

(d) Approval of Payment Advices (PAs)

i. Typed PAs accompanied by respective AC files are taken to Head, PDS for

signature

ii. Head Accounting Unit (Senior Principal Accounts Controller [SPAC]) will

provide the Second Signature

iii. Coding of the PAs by Head, Accounting Unit (SPAC)

iv. PAs submitted to the Director, DMD for endorsement

v. The Permanent Secretary/Treasury approves the PAs and forwards to

Head, PDS

vi. Controller & Auditor General audits the approved PAs.

(e) Payment of the PAs

The Head, PDS will:

i. submit PAs accompanied by a schedule of all the PAs signed by two

authorized signatures to Central Bank of Kenya (CBK)

ii. use CBK acknowledged schedule of PAs to update the Payment Monitoring

Report

iii. receive Debit Notes from CBK

iv. Counter check Debit Notes against CBK acknowledged

(f) Record payment transactions

i. Forward Payment Monitoring Report to Head, DRS

ii. Head, DRS to update CS-DRMS data base using Payment Monitoring

Report

iii. File Payment Monitoring Report.

(g) Generation of management reports


11

The following management reports must be generated by the Head, DRS at the

beginning of every month and submitted to the Director DMD.

i. Payments falling due during the month, report 300 from CS-DRMS system

ii. Actual payments during the previous month

iii. Arrears position

iv. Disbursements

v. The Debt Stock position

CHART 1: THE PA PREPARATION PROCESS.

Director, DMD Receives and Okays Demands Notices for Payment

Debt Recording Section (DRS) Verifies Demand Notices against the CS-DRMS System Updates CS-DRMS using the debit note

PS, Treasury Signs Payment Advices (PAs)

Public Debt Section (PDS) Initiates Preparation of Payment Advices Retrieves AC files Signs prepared PA.

Senior Principal Accounts Controller Codes the PA Signs the PA

Controller & Auditor General Audits the PAs

Central Bank of Kenya (CBK) Effects the Payments to the Creditors Sends Creditor’s acknowledgment to PDS Sends Debit notes to PDS

1

2 3

4

5

6

7

8 9

10

11

12


12

CHAPTER THREE

3. Proposed Automated Public Debt Payments System Design

Having reviewed the existing manual Payment Advice preparation process, this

chapter articulates the requirements for an automated system.

3.1 Objectives of the New System

The general objective of the Payment Advice Printing System is to develop a

system integrating the Payment Advices preparation process with the CS-DRMS

data. The data will be used for printing the Payment Advice forms.

3.2 Specific Objectives The system will have several objectives. These are:- § Address the problems of manual preparation of the Payment Advices;

§ Ensure that only loans registered in the CS-DRMS system are serviced;

§ Ensure that only loans forecasted for payments are serviced at any

particular time;

§ Ensure that amounts on the demand notices are also verified against the

forecasted amounts;

§ Ensure that payments are made to creditors registered in the CS-DRMS

system;

§ Ensure that only authorized personnel are allowed to prepare the Payment

Advices.


13

3.3 System Requirements

A solution to integrate the Payment Advice preparation process with the CS-

DRMS was sought to address the issues raised above. The solution was geared to

satisfy the requirement for automation of the payment process.

TABLE 1: SYSTEM REQUIREMENTS System type - a fully computerized solution as opposed

to the current semi-computerized system;

Processing methods and procedures - system to exhibit a high degree of on-line

processing support to facilitate faster

access of information;

Information storage/retrieval methods - system to implement a database oriented

solution to facilitate easy and flexible

storage and retrieval of information;

Internal controls - system to ensure high level of security

and reliability;

User interface - system must provide reasonably user-

friendly man-machine interactions;

Necessary equipment - to have enough capacity and processing

Computer programs - to have capabilities to exhibit all the

characteristics mentioned above;

End-user roles and functions - System to preserve job descriptions as

much as possible while transforming

users into more productive beings. This

will be achieved by training the existing

staff in the Back Office.


14

Design and Construction - To employ the popular interactive

prototyping methodology. This is a

participatory approach where the user and

the systems analyst work closely together

to ensure that the information system

addresses all the user requirements.

3.4 Data Requirement

A Payment Advice (PA) form has the following details ;

1. The A/C (Account) file reference number. This is a unique number that the

Back Office uses to reference the particular file that contains the loan

agreement and any transactions that have taken place in the past for that

particular loan. It also contains copies of demand notices.

2. The associated loan key number as recorded in the Commonwealth

Secretariat Debt Recording and Management System (CS-DRMS)

3. The payment date – Usually the day of printing the Payment Advice.

4. The account to be debited. This is the Ministry of Finance’s account held at

the Central Bank.

5. The currency and total payment amount, both in figures and in words

6. The receiving bank’s name and address

7. The beneficiary’s name and address

8. A breakdown of the payment, the creditor’s reference number and title for

the loan being paid

9. The due date for the payment.

10. The Payment Advice signatories

Following a review of the above PA data requirements, the necessary sets of data

of the PAPS were identified as depicted in the table below. Most of the data is

already stored in the CS-DRMS.


15

TABLE 2: DATA SETS 3.5 Data-Sets of the PAPS System

1. PAData The actual details of the PA, including number and date.

2. Demand Bill details, including the actual part-payments.

3. LoanData Loan details as recorded in the agreement.

4. PayTypes The various types of payments, including penalties.

5. Payments All payments that have been made to creditors

5. Lenders Creditors details – updated periodically

6. Currencies Currencies used

7. Banks Bank details, including IBAN and SWIFT

8. Defaults CBK-authorized PA signatories.

9. PAPSUsers System User access rights and privileges in the system

3.6 Mapping of data elements to PAPS entities.

The study further maps the data elements to the detailed PAPS entities as

depicted in the following tables.

TABLE 3: PADATA TABLE Table Name PAData

Primary key PANum

Description The actual details of the Payment Advice (PA), including PA number

and Print date. This table will store all PAs that have been authorized

for printing. It will also store any cancelled PAs. Field Name Field

Type

Characters Description

PANum Long 7 Number of the PA

LoanNum Long 7 Loan number as appears in CS-DRMS system

PADate Long 8 Date of the PA

DueDate Long 8 Payment due date as per demand note


16

CurrCode String 3 PA Currency

PrintDate Long 8 Date when original PA is printed

CopyDate Long 8 Date when a copy of PA is printed

DatePaid Long 8 Date when CBK debited the PA

ExChRate1 Decimal 6.4

Exchange rate used for requisitioning cash from

exchequer

ExChRate2 Decimal 6.4 Exchange rate at time of debiting the PA

Replacer Long 7 Number of the PA

Sign1 String 25 First Signatory

Sign2 String 25 Second Signatory

Sign3 String 25 Third Signatory

Sign4 String 25 Fourth Signatory

LoanRef1 String 30 Creditors original loan reference

LoanRef2 String 30 Creditors new reference if current one changed

LenderCode String 4 Beneficiary name and address

BankCode1 String 10 Receiving Bank

AccountNum1 String 40 Repayment account number held at BankCode1

BankCode2 String 10 Correspondent Bank


TABLE 4: FOREIGN KEYS IN PADATA TABLE Table Name Relating Column/s

LoanData LoanNum

Demand LoanNum,DueDate

Bank BankCode

Currency CurrCode

Payment LoanNum, DueDate

Lender LenderCode


17

TABLE 5: DEMAND TABLE Table Name Demand

Primary key LoanNum, DueDate

Description Bill details, including the actual part-payments. When a demand bill is

received, the details are stored in the demand table. This data is not

approved as yet for payment Field Name Field

Type



DueDate Long 8 Date when the payment is due as per demand note

CurrCode String 3 PA Currency












TABLE 6: FOREIGN KEYS FOR DEMAND TABLE Table Name Relating Column/s

LoanData LoanNum

PAData LoanNum,DueDate

Bank BankCode

Currency CurrCode


Lender LenderCode

Signer PNum


18

TABLE 7: BANK TABLE Table Name Bank

Primary key BankCode

Description Bank details, including SWIFT. Some Creditors don’t give the

SWIFT.

Field Name Field

Type


BankCode String 10 Bank Code

BankName String 50 Full name of the bank

SWIFT String 20 International Bank Identifier Code

Address String 255 Bank’s address

TABLE 8: FOREIGN KEYS FOR BANK TABLE Table Name Relating Column/s

LoanData BankCode

PAData BankCode

Demand BankCode

TABLE 9: PAYMENT TABLE Table Name Payment Primary key LoanNum, DueDate, PTypeCode

Description All payments that have been made to creditors. This is the table with

all transactions that have taken place.

Field Name Field

Type



DueDate Long 8 Date when the payment is due as per demand note

PTypeCode Byte 2 Code for Type of Payment

Amount Decimal 15.2 Loan Amount For Specific Payment Type


19

TABLE 10: FOREIGN KEYS FOR PAYMENT TABLE Table Name Relating Column/s

LoanData LoanNum, DueDate

PAData LoanNum,DueDate

PayType PTypeCode

TABLE 11: LOANDATA TABLE Table Name LoanData

Primary key LoanNum

Description Loan details as recorded in the agreement. This is the

instruments table with details of each particular instrument Field Name Field

Type



LoanTitle String 100 Brief description of the Project

LoanDate Long 8 Loan Agreement Date

LoanFile String 20 Reference number given in accounts

Amount Decimal 15.2 Original Loan Amount

CurrCode String 3 Original Loan Currency








TABLE 12: FOREIGN KEYS FOR LOANDATA Table Name Relating Column/s

PAData LoanNum

Bank BankCode

Currency CurrCode


20

Table Name Relating Column/s


Lender LenderCode

TABLE 13: PAYTYPE TABLE Table Name PayType

Primary key PTypeCode

Description The various types of payments, including penalties. It is good to

note that payments made are either interest or principal, but there

is a need to include the penalties as well. Field Name Field

Type


PTypeCode Byte 2 Code for Type of Payment

PtypeName String 50 Full description of the type of payment

ShortName String 15 Abbreviated name, either interest or principal

CSDRMSCode String 3 Code used by CSDRMS system

TABLE 14: LENDER TABLE Table Name Lender

Primary key LenderCode

Description Creditor’s details – updated periodically. In payments the lenders are

the payment receiving agencies. Field Name Field Type Characters Description

LenderCode String 4 Creditors Code

LenderName String 100 Creditors Full Name

Address String 100 Creditors Contacts

TABLE 15: FOREIGN KEYS FOR LENDER TABLE Table Name Relating Column/s

LoanData LenderCode

PAData LenderCode

Demand LenderCode


21

TABLE 16: CURRENCY TABLE Table Name Currency

Primary key CurrCode

Description Currencies used in payment of the loans.

Field Name Field

Type


CurrCode String 3 Payment Currency

CurrName String 50 Full name for the currency

WBCode Short 3 World Bank Equivalent code

TABLE 17: FOREIGN KEYS FOR CURRENCY TABLE Table Name Relating Column/s

PAData CurrCode

LoanData CurrCode

Demand CurrCode

TABLE 18: DEFAULTS TABLE Table Name Defaults

Primary key RowNum

Description Central Bank of Kenya’s authorized PA signatories. The CBK will

check the PA signatories against their signatures. Field Name Field

Type


RowNum Long 14 Unique Record Counter






22

TABLE 19: PAPSUSER TABLE Table Name PAPSUser

Primary key Pnum

Description System User access rights and privileges in the system Field Name Field

Type


PNum Long 10 Employee's(User) Personal Number

UserName String 40 Employee's Name

DCode Short 2 Employee District

UserID String 20 User Identifier

SuperUser Byte 3 Super User

SubSystem Byte 3 Subsystem to access

Edit Byte 3 Allow to edit

Print Byte 3 Allow to print

AccessDate Long 6 Last access date

AccessTime Long 6 Last access time

The tables are represented diagrammatically as below;


23

CHART 2: SCHEMATIC VIEW OF THE TABLES

PayType

PAData Demand Bank

Payment Lender

Currencies LoanData Defaults


24

CHAPTER FOUR

4. Using CS-DRMS for External Loans Payment. The purpose of the study of automating the debt service payment process was to

design and proto type a software facility that would enable the printing of the PA

using a computer and a printer in the shortest possible time in an efficient manner.

This was achieved using the above entities. The choice of these entities was done

in such a way that they would relate to those in the CS-DRMS schema. The

reason for doing this is to enable future deployment of the Payment Advice

Printing System into the CS-DRMS schema would be done with ease.

The system was installed in a server and users accessed the system from their

workstations via the Local Area Network (LAN) already in place.

To ensure some level of security, each user had a user logon name and password

to access the system. Users were also assigned different roles to enhance

security. The roles include Administrator, Controller, Manager, Supervisor and

Operator.

In the system, no PA can be printed unless the system’s supervisor authorizes it.

Further only the system’s manager has the right to edit or enter a new loan in the

system. The system’s Controller was responsible for editing the look up tables,

whereas the system’s operator prepared the demands and printed the duly

authorized PAs.

A careful look at the data requirements shows that the CS-DRMS 2000+ has

almost all the data required for preparing a PA.

Data present in CS-DRMS.

1. All details on Currencies


25

2. All details on Instrument Details

3. All details on Beneficiaries (Agencies)

4. All details on Payment Types

Data not available in the system.

1. Bank details

2. Account Numbers

3. Payment Advice numbers (Voucher Numbers)

4. Signatories


26

CHAPTER FIVE

5. Conclusion Using the Kenya’s example the study has found out that the current payment

process takes not less than five hours from receipt of the demand note to the time

it is ready for signature. The designed tool in this study is estimated to take less

than fifteen minutes. Whereas in the current system, anyone with access to the

payment advices can type in payment instructions, the proposed tool ensures that

only authorized personnel have access to the tool. It has been revealed in this

study that there is reduction in the typo errors.

One way of measuring the effectiveness of a back office in Debt Management

Office is by the accuracy and timeliness of payments of debts. This study, by

integrating the payment process with the CS-DRMS system, has demonstrated it

is possible to significantly reduce the process of settling payments and improving

on the accuracy.

However there are a few areas that need further research, namely:

1. CS-DRMS software requires that each transaction be done on loan by loan

basis, however, with some creditors whose loans may be falling due on the

same dates it would be more cost effective if the payments are aggregated to

reduce cabling costs. The developed tool does not aggregate payments and

therefore, further research would be vital to reduce cabling costs.

2. Further enhancement in the payment process could be made by introduction of

the electronic signature, in which the digitized PA form would be electronically

transmitted to the Central Bank of Kenya. This will be an area of further

research.


27

REFERENCES

ComSec, 2006 January, Debt Management Section Special Advisory Services

Division Commonwealth Secretariat Administration Manual, London, United

Kingdom


Division Commonwealth Secretariat Domestic Debt Manual, London, United

Kingdom


Division Commonwealth Secretariat External Debt Manual, London, United

Kingdom


Division Commonwealth Secretariat Management Tools Manual, London, United

Kingdom


Division Commonwealth Secretariat Reports Manual, London, United Kingdom

UNCTAD, The United National Centre on Trade and Development Website

http://r0.unctad.org/dmfas/

ComSec, Commonwealth Secretariat Website http://www.csdrms.org/


28

ANNEX 1: BLANK PA FORM


29

ANNEX 2: ELECTRONICALLY FILLED PA FORM

using the cs -drms 2000+ in settlement of foreign...

Documents