THE COMPUTER SOCIETY OF ZIMBABWE

CSZ SFI VER 4 (2009)

COMPUTER SOCIETY OF ZIMBABWE

IT STANDARD FOR

STANDARD FILE INTERFACE (S.F.I)

ELECTRONIC PAYMENTS

Version 4 of 2009

CSZ TECHNICAL LIAISON COMMITTEE Copyright 2009 Computer Society of Zimbabwe

THE COMPUTER SOCIETY OF ZIMBABWE

Standard File Interface for Electronic Payments Version 4

Background
The first version of the Standard was developed by the then Zimbabwe EFT User Group (ZEFTUG) in 1994, as a result of the perceived need for an electronic media standard for salary deposit data and similar banking transactions. The group included representation from all banks and building societies, insurance council and insurance brokers association, the government Salary Service Bureau , and other interested parties. ZEFTUG was subsequently incorporated into the Computer Society of Zimbabwe as a Special Interest Group for EFT (Electronic Funds Transfer). The original standard (Version 1) was adopted in 1994, and modified shortly afterwards as Version 2 and was successfully implemented by almost all organisations involved. In 2003, suggestions were received to modify the standard in keeping with current requirements. Once again all significant organisations in the financial sector were consulted and finally advised of the proposed amendments. Version 3 was published by the Computer Society of Zimbabwe in July 2003, with the recommendation that this version replace all previous versions as from April 2004. Following the introduction of multi-currency payrolls, the standard was modified and updated to suit current conditions in February 2009 as Version 4. The size of amount and account number fields was increased , optional currency code fields were added as well as an inflation index.,

Enquiries
The Computer Society of Zimbabwe Secretariat 6 Baines Avenue, Harare. P O Box CY164,Causeway, Harare Tel: (04) 250489/90 Fax: (04) 708861 International dial code : (+263) Email: info@csz.org.zw

CSZ TECHNICAL LIAISON COMMITTEE Copyright 2009 Computer Society of Zimbabwe

THE COMPUTER SOCIETY OF ZIMBABWE

Standard File Format for Magnetic Media Transfers of Electronic Payment Transactions Final Draft of Version 4 25th February, 2009

1. File Format The file will consist of ASCII records. There are three record formats to each file: a header, detail records, a trailer record. The format definition below uses an X to indicate an Alphanumeric character and a 9 for a numeric digit. All dates are held in yyyymmdd format. All monetary values will be held as the number of cents, with no decimal place. The field names below on the far left are only suggested names.

CSZ TECHNICAL LIAISON COMMITTEE Copyright 2009 Computer Society of Zimbabwe

THE COMPUTER SOCIETY OF ZIMBABWE

2. Control Records There will be two control records on the file the first and last records. The first record on the file is the header record consisting of the following fields:
FIELD Header-ID Process-Date Sender-ID Receiver-ID File-ID Work-Code SFI-Version Sender-Name Receiver-Name Package-Name FORMAT XXX 9(8) X (9) X (9) 9(6) X (15) 999 X(30) X(30) X(30) COMMENT Contains UHL for User Header Label In yyyymmdd format As specified by the relevant financial institution As specified by the relevant financial institution Serial number of file. It is intended that this will be incremented by 1 each time a particular organization creates a new file. As specified by the relevant financial institution e.g. SALARY DEPOSITS Standards version number (004) Optional, specified by the relevant financial institution. Left blank if not used. Optional, specified by the relevant financial institution. Left blank if not used. Name of software package and version number. Left blank if not used.

There are 143 characters in the record.

The second control record is the trailer record, which is the last record on file.
FIELD Trailer-ID Currency-Code Debit-Value Credit-Value Debit-Rec-Cnt Credit-Rec-Cnt Checksum Checksum-Tot FORMAT XXX XXX 9(24) 9(24) 9(6) 9(6) 9(6) 9(12) COMMENT Contains UTL for User Trailer Label Currency of totals Total value of Debits in Cents Total value of Credits in Cents Number of Debit records. N.B. does not include the header and trailer records in the count. Number of Credit records. N.B. does not include the header and trailer records in the count. Optional, specified by the relevant financial institution Optional, specified by the relevant financial institution

There are 84 characters in this record. Individual batches will, as a rule, be of a single currency and all transactions in a batch will be of the same debit account (credit account for Debit Orders). However, should a batch contain more than one currency, there will be more than one Trailer record, each totalling the details for that currency.
CSZ TECHNICAL LIAISON COMMITTEE Copyright 2009 Computer Society of Zimbabwe

THE COMPUTER SOCIETY OF ZIMBABWE

3. Detail Records
FIELD Rec-Type Dest-Sort FORMAT XXX 9(7) COMMENT Record type. e.g. PAY Destination Bank Sort Code see Coding of Financial Institutions, below. Where the file is being sent to a non-financial institution and contains details of data deducted on behalf of other organisations (e.g. for an insurance company carrying details of payments deducted against salary) this field will be blank. (Right Justified) Destination Account Number, prefixed by branch code if applicable. If for non-financial institution, left blank as per previous field. When numeric this field should be right-justified, left zero-filled. Destination Account Type as specified by the financial institution. Optional when blank assumed to be as per Amount-curr-code ISO 4217 alphabetic code indicating Destination currency Optional - when not used leave blank Value by which Amount must be multiplied to convert from Amount-Curr-Code to Dest-Curr-Code - see explanation below Transaction Code as specified by the financial institution. Originators Bank Sort Code see Coding of Financial Institutions, below. Origination Account Number. When numeric these should be right-justified, left zero-filled. Origination Account Type as specified by the financial institution. Optional when blank assumed to be as per Amount-curr-code ISO 4217 alphabetic code indicating Originating currency Optional - when not used leave blank Value by which Amount must be multiplied to convert from Amount-Curr-Code to Orig-Curr-Code see explanation below Relevant Reference Data as specified by the financial institution. In most payroll systems this will be the National Id Number Surname and Initials Value of Transaction in Cents ISO 4217 alphabetic code indicating Transaction currency Eg USD, ZWD, ZAR, BWP Optional when not used leave blank - value then presumed zero See details below Processing Date in yyyymmdd format Blank as specified by the financial institution. Second reference field. Used for relevant reference data. For instance, with insurance deductions this field will contain the policy number. Use as specified by financial institution. Third reference field. Used for relevant reference data. Use as specified by financial institution. Fourth reference field. Used for relevant reference data. Use as specified by financial institution. Optional. When not used leave blank. See notes below on calculation of checksum

Dest-Account

X (20)

Dest-Acc-Type Dest-Curr-Code Dest-Curr-Rate

XX XXX 9(24)

Trans-Code Orig-Sort Orig-Account Orig-Acc-Type Orig-Curr-Code Orig-Curr-Rate

99 9(7) X (20) XX XXX 9(24)

Reference-1 Dest-Name Amount Amount-Curr-Code Power-10 (inflation index) Process-Date Unpaid-reason Reference-2

X (15) X (30) 9(24) XXX 999 9(8) 99 X (30)

Reference-3 Reference-4 Checksum

X (30) X (30) 9(6)

There are 298 characters in this record.

CSZ TECHNICAL LIAISON COMMITTEE Copyright 2009 Computer Society of Zimbabwe

THE COMPUTER SOCIETY OF ZIMBABWE

Coding of Financial Institutions The banks in Zimbabwe use a five-digit numeric code. This has been widely accepted as the RBZ code for Reserve Bank of Zimbabwe. On occasion it has been difficult for software developers and users to get an updated, consistent, standard list of all the RBZ codes. There has also been some confusion regarding the codes for other institutions such as the building societies. To reduce the effort of many individuals and organizations trying to ascertain exactly which codes to use, the CSZ will make available the standard RBZ list on request. The list will be a simple text file with the following columns: Code Organisation name Branch name Abbreviated Name Abbreviated Branch 5 digits (e.g. 02144) 40 characters (e.g. Barclays Bank) 40 characters (e.g. Pearl House) 12 characters (e.g. Barclays) 12 characters (e.g. Pearl Hse)

The bank codes on the SFI file allow for 7 digits to conform with international standards, but the first two digits will always be zero-zero, followed by the five-digit code.

Currency Rate: No decimals - Rate * 1000000 e.g. 500 represents 0.0005

Power-10 (inflation index) : Where the Amount field has been debased, the calculation to restore it to the full value is : Amount = 10E*Power-10. This applies to the Amount field not to the Equivalent fields Example 1: Amount = 200, Power-10 = 6 (i.e. add six zeroes) Full value = 200 million cents Example 2: Amount = 200, Power-10 = -2 (ie drop two zeroes) Full value = 2 cents

CSZ TECHNICAL LIAISON COMMITTEE Copyright 2009 Computer Society of Zimbabwe

THE COMPUTER SOCIETY OF ZIMBABWE

Checksum Since the standard data interchange was introduced, there have been a number of incidents in which individuals have fraudulently amended the data interchange file after it was generated, but before it was transferred to the financial institution. The purpose of the checksum on each transaction record, and then the total checksum on the trailer record is to reduce the opportunity of successfully tampering with the file. A checksum works more or less like a check digit. If the data from which it is derived is amended, there is a very good chance that a different value for the checksum will be needed to maintain consistency within the record. As far as the data interchange record is concerned the fields that need to be carefully controlled are the value and the account numbers. Any alteration to these fields needs to be identified immediately by the recipient. It is not the intention here to publish the full details of the proposed algorithm to calculate the checksum, as the fewer people who have access to the calculation method the better. The algorithm will be made available to software developers only, and then on the understanding that they will treat it with the utmost confidentiality. However, to get some idea of what is proposed, a simple example of the calculation of a checksum on an account number will be used. In the table below the account number is 000123456789123 and the checksum weights are 3, 5, 7, 11, 13, 17, 19, 23, 29, 31, 37, 41, 43, 47, 53. By using this standard list of prime numbers the risk of getting the same checksum by transposing digits is significantly reduced. The value of each account number digit is multiplied by its corresponding weight and then summed, giving the checksum. Digit Weight Multip ly 0 0 0 3 5 7 0 0 0 1 1 1 1 1 2 1 3 2 6 3 1 7 5 1 4 1 9 7 6 5 23 11 5 6 29 17 4 7 31 21 7 8 37 29 6 9 41 36 9 1 4 3 4 3 2 4 7 9 4 3 53 15 9

Summing up the bottom line one gets 1631 and this would be the checksum. It is emphasised that this is simply an example of just one way to calculate a checksum. The weights can easily be varied, and one is obviously not restricted to simply multiplying and adding the results. The method that would be used for the standard will be decided on by a committee of software developers.

CSZ TECHNICAL LIAISON COMMITTEE Copyright 2009 Computer Society of Zimbabwe