Decision No. 1630/2003/QD-NHNN of December 19, 2003, on the issuance of the regulation on technical standards in the processing, procurement of banking operation software

DECISION

ON THE ISSUANCE OF THE REGULATION ON TECHNICAL STANDARDS IN THE PROCESSING, PROCUREMENT OF BANKING OPERATION SOFTWARE

THE GOVERNOR OF THE STATE BANK

- Pursuant to the Law on the State Bank of Vietnam No. 01/1997/QH10 dated 12 December, 1997 and the Law on Credit Institutions No. 02/1997/QH10 dated 12 December, 1997;
- Pursuant to the Law on the amendment, supplement of several Articles of the Law on the State Bank of Vietnam No. 10/2003/QH11 dated 17 June, 2003;
- Pursuant to the Decree No. 86/2002/ND-CP dated 05 November, 2002 of the Government providing for the function, assignment, authority and organization structure of Ministries and ministerial-level agencies;
- Upon the proposal of the Director of the Banking Information Technology Department,

DECIDES:

Article 1.To issue in conjunction with this Decision "the Regulation on technical standards in the processing, procurement of banking operation software".

Article 2.This Decision shall be effective after 15 days from the publication in the official gazette.

Article 3.The Director of the Administrative Department, the Director of the Banking Information Technology Department, Heads of units of the State Bank, General Managers (Managers) of Commercial Banks, the Central People Credit Fund shall be responsible for the implementation of this Decision.

REGULATION

ON TECHNICAL STANDARDS IN THE PROCESSING, PROCUREMENT OF BANKING OPERATION SOFTWARE
(Issued in conjunction with the Decision No. 1630/2003/QD-NHNN dated 19 December, 2003 of the Governor of the State Bank)

Chapter I

GENERAL PROVISIONS

Article 1.Governing scope

1. This Regulation shall include basic technical standards, procedural sequences in the processing, procurement, deployment and operating support for banking operation software of the State Bank, Credit Institutions (hereinafter referred to as units) in order to universally manage the application of information technology to banking activities for great efficiency and asset security.

2. This Regulation shall not govern the operation software, which is used for the purpose of research, trial or partially used at a location and not connected to the common operation software of units.

3. The hire for processing, procurement of banking operation software shall also be subject to provisions of the State on the hire and procurement of goods and services besides this Regulation.

Article 2.Interpretation

In this regulation following terms shall be construed as follows:

1. Program shall be a group of instructions, commands, which are written in a specific language and directly or indirectly used on the computer or other devices with information processing capability to obtain a certain result.

2. Software shall include program, technical documents and related data, which are used in the program.

3. Banking operation software shall be the software applicable to operational activities of the bank in order to informaticalise partial or entire activities of that operation.

4. Packed software shall be software that is produced in mass and sold in form of completely packed products.

5. Program module shall be a part of the program, which is separately written and checked, combined thereafter with other modules to make a complete program.

6. Open software shall be software, which complies with national and international industrial standards in terms of the openness and high compatibility for changes of the system and operation requirements

7. Software version shall be a series of numbers tied to the issuance of software products. There are two types of version: main version and upgraded version; Main version shall be the one, which is written after the first development and several considerable changes in structural organization and function of the software; upgraded version shall be the one, which is used in the process of error correction and update of arising queries.

8. Software license shall be a legal confirmation on the right to exploit the software under interests provided for by that license.

9. System shall be an organizational combination of the software, devices and other related factors under a certain standard in order to enhance the effectiveness of the common usage.

10. System design shall be a translation work that requires operations and users to make a detailed technical model to direct the development of software.

11. Configuration shall be a collection of programs, materials, data that are adjusted under a certain technical requirement.

12. Sample shall be a model reflecting the design, programming ideas or operation settlement process that help the imagination, assessment and orientation of work before performance.

13. Library of sample programs shall consist of standard programs that are collected for the purpose of common use and used for many times.

14. Software adjustment shall be the amendment, supplement of components of the software to make it more appropriate with users requirements.

15. Software testing shall be the testing, experiment of the software to discover errors in terms of operation settlement, programming, interface or interaction between program s modules and determine the satisfaction level for given requirements of the software that needs testing.

16. Examining situation shall be a collection of input elements, data, operational conditions and expected result. Examining situations are prepared to satisfy a certain objective such as checking a certain function of the program, durability of system, users requirements and other requirements (if any).

17. Examining procedures shall be a set of instructions to set up, implement and assess the result of one or several examining situations.

18. Examining program shall be a program used to automate the performance of examining procedures. Examining program may be prepared by programming or automatically arisen by examining instruments.

19. Operation and users requirement analysis shall be a process of study and description of operation problems, users requirements, the relationship between them and the feasibility analysis of those requirements in the application of informatics to certain conditions.

20. Software deployment shall be the study of technical solutions, procedure establishment, training organization, installation, operational instruction, initiation, data conversion and putting the software into operation.

21. Software warranty and maintenance shall be the management of changes, provision of support to secure the accurate, smooth and safe operation of the operated and deployed software.

22. Management of software configuration shall be the establishment, preservation, issuance of software products and systematic control of their changes.

23. User shall be the person who is assigned to operate the program to carry out his tasks in accordance with his assigned authorities and responsibility.

24. System administrator shall be the person who is assigned to manage and secure the smooth and safe operation of the system.

25. Processing of operation software shall be the entire process of operation and users requirement analysis, systematic design analysis, program composition, guiding documents, testing, experiment and package of the software.

Article 3.Software license

Operation software used in banking activities should be supported by usage license in accordance with provisions of applicable laws. Any act of illegal usage, intervention such as: replacement, copy, disclosure of design, algorithm, technology and source code shall be strictly forbidden.

Article 4.Software upgrade

Software update shall mean to timely overcome program s shortcomings, reflect changes in operations and replace backward algorithm and technology. The duration between upgrade times should exceed the amortizing time provided for software.

Chapter II

BASIC TECHNICAL STANDARDS OF BANKING OPERATION SOFTWARE

Article 5.Selection of technology and software solutions that

1. can settle operation requirements well, can be deployed and applicable to the fact and have longevity.

2. secure safe and confidential standards of operation.

3. comply with the design standards of open software system.

4. are in line with technology level, financial status and effectively use investment fund sources of the unit.

Article 6.Requirements of safety and confidentiality

1. To assess potential risks of the system in the course of the analysis, system design, to classify the importance of each component and the entire system.

2. To specifically stipulate and sufficiently prepare technical conditions, environment for the safe installation and manipulation of operations.

3. To prepare back-up plans for breakdowns settlement in line with operational features in terms of permitted maximum interruption time, importance of data.

4. To control, prevent the illegal access to the system and to take timely measures for limiting and overcoming consequences (if any).

5. To control operation acts, only to permit users to operate in accordance with their assigned function, tasks. To warn of operation acts that may cause the failure, loss of data or affect the operation of the system.

6. To take measures in respect of the source code examination and identification, data protection and encryption from data of the level "Confidential" upward in banking area when the exchange on the network is carried out.

7. Software for the data encryption, electronic signatures must be set up, managed and used in accordance with the "Top secret" regime in the banking area

Article 7.Open design and stable operation

1. The design program shall be relatively independent to components of the hardware, operating system, databases and communication of the system; input elements, program installation shall be parameterized and divided into sub-program modules under their functions, which can be extended and connected to other operation software in the near future.

2. The design program must be able to operate with stability, the result of which must comply with operation requirements and may deal with arising exception errors.

Article 8.User interface

1. All program must be consistent in terms of screen layout, color, menu, font and the convention on the use of icons, function keys in accordance with common standards; the way of program outgoing and incoming and performance must be consistent.

2. To arrange program functions under scope, task groups and procedures for operation performance; to provide online support and eliminate redundant acts in operating process.

3. To warn and prevent unintentional errors during operating process, not to permit users to carry out assignments beyond their assigned competence

Article 9.Interface with other operation software.

1. Connection to related operation software, except for examination purpose, shall be kept uninterruptedly; the collection, transmission, processing and preservation of information shall not be coincident.

2. Issued codes shall be used consistently for the same operation subject referred to.

3. To secure the safety in the connection, to avoid the access to or illegal intervention with the data of others .

Article 10.Technical documents

1. Technical materials that must be issued in conjunction with the program shall include:

a. Documents on equipment configuration of hardware, network, operating system, database and other equipment that shall be used for s

b. Documents guiding the system installation and operation.

c. Documents guiding the preservation and recovery of programs, database.

2. Documents issued for the first version and update versions should be sufficiently preserved to facilitate the looking up when necessary.

Chapter III

PROCESSING, DEPLOYING AND SUPPORTING THE OPERATION OF BANKING OPERATION SOFTWARE

Article 11.Making plan, examining and handing over assignment results

1. The plan should be made for each design, construction, deployment, support and operation of the software and upon its completion; the result should be considered and approved.

2. The plan and examination report shall consist of following contents: the scope, objectives, time, human resource, cost and other implementing conditions; points of time, examination standards and received results.

Article 12.Operation and user s requirement analysis

1. Operation investigation

a. To study operation documents: procedures, process, guiding documents and other documents provided by users.

b. To list issues, questions that need investigating

c. To investigate practical operation activities and interview users

d. To consolidate documents and make investigation report

2. Operation analysis

a. To analyze operation requirements, organizational features, technical environment, legal environment and users characteristics.

b. To prepare documents on modeling operation settlement process, data flow and information carriers.

3. Analysis of users requirements

a. To prepare documents on description and classification of requirements of functions, operation environment, operation requirements, and other requirements from the users viewpoint.

b. To analyze the feasibility, consistence and appropriateness of requirements and determine the priority, criteria and conditions of requirement satisfaction.

c. To prepare a sample form in the event of necessity.

d. To consult with the user to eliminate unreasonable or infeasible requirements; to deal with conflict requirements, study and supplement new requirements (if any).

4. Description of system operation and users requirements

a. To prepare documents to describe the design, operation of the system at present and expected in the future: operational process, acts, operational ties, cases and their solutions.

b. To prepare documents that focus on users requirements: description of requirements concerning function, interface, data organization, operation, equipment requirements and other requirements from the viewpoint of technical officers.

c. To confirm the result with users.

5. Operation officers shall be responsible for sufficient, timely provision of operation documents, responses to investigation requirements and confirmation of the correctness of the report on operation analysis if required.

Article 13.Analysis and design of the software system

1. Study of design requirements

a. To classify and describe requirements; to determine standards, provisions, procedures and guidance on design; to study similar problems, the capability of re-utilization of available designs and determine necessary instruments.

b. To consider and ensure the sufficiency, reasonability of requirements on function and implementing levels, the legality of legal requirements; to deal with unclear requirements and conflicts among requirements.

2. Overall design

a. To study documents that focus on users requirements and determine basic elements of system design such as: technical models, operation, database organization and organization of program system; security issues, secrecy, management and operation and prepare a sample form, if required.

b. To select measure, standards and instruments of design

c. To prepare an overall design document on program and data.

d. To consider the feasibility of documents prepared for the detailed design period and program under the design

3. Detailed design

a. To design screen and user interface, reporting forms, settlement algorithm and interface with other operations; the level of security and secrecy of data and other design contents.

b. To select database, programming language, instruments and other technologies concerning construction, organization and deployment of the operation software.

c. To prepare technical document that specifies requirements to users and operating environment of the operation software.

d. To consider, assess design documents, the feasibility and the readiness to program.

Article 14.Program writing

1. Standards for writing program codes

a. Program notes: general description, correction time, corrector, examiner and correction content at the beginning of the program; notice taking, explanation of complicated code sections that can easily lead to the mistake or for the explanation of program processing.

b. To display the structure of program sources in a consistent manner and certain order.

c. To name objects of the entire program consistently. The name must create a reminding mean, reflect the entire or partial scope and be distinguishable between other types of objects. The way to name and file forms shall be in line with contents and standards of software instruments.

2. To design, program library modules for common usage.

3. Program and combination of functional modules

a. To program functional modules under the systematic design documents that are prepared in previous stage; to examine, consider and combine them to make a complete program.

b. To set up an environment, examine each separate module and the entire program in accordance with the requirements of the design documents.

4. Writing documents that describe systematic function

a. The overall function of the software to be set up

b. Main functions of the system: structure diagram, interfaces of the system and data lines.

c. Requirements of the system: supporting data, configuration of equipment and operating environment.

d. Software structure: source code library, implementing program, support program of the software.

5. Writing instrument, documents of installation and operation guidance

Article 15.Experimental examination and software correction

1. Making plan for examination

a. Examination requirements and standards for products assessment

b. Examination scope: limit of work, human resource, main periods in the examining schedule, time, implementation cycle and repeat examining steps.

c. Examining methods

d. Resources and examining: number of persons and skill, examining environment for hardware, software, network infrastructure and examining instruments.

2. Setting up examining scenario

a. To prepare examining list

b. To set up examining situations for regular and irregular cases of the system, environment and operation of the program.

c. To set up examining procedures including: conditions for the begin, end of examination, implementation steps and necessary examination data.

d. Examination criteria: general assessment, implementing productivity, durability and irregular situations.

3. Carrying out the uninterrupted examination

a. To set up examining environment that imitates practical operating conditions of operation software.

b. To examine under the scenario, take notice of the result and discovered errors.

c. To deal with arising errors and reexamine after settlement

4. To consider and assess results of the examination

a. To analyze errors in accordance with the level of repeat, seriousness, time for error correction and to recommend the settlement.

b. To assess the achievement ratio through examination

c. To make consolidated examination report, to assess the satisfaction level of software s requirements and capability of practical deployment and operation.

5. Examining officers shall operate independently from officers who write program, clearly understand documents concerning the system design, operational requirements and take full responsibility for the quality of examined products.

Article 16.Training

1. Requirements of the training

a. The training shall be performed prior to or together with the deployment process of software.

b. The training should be carried out for right subjects.

c. Training environment shall imitate the practical operation.

d. The operation documents must be sufficient.

dd. Trainees of software courses that require high operational skills shall be examined and granted a certificate of software use.

2. Training performance

a. To prepare training program: content, forms, requirements and conditions for implementation.

b. To prepare environment, documents, data and guidance.

c. To carry out the class training or on the job guidance.

d. To consolidate, assess results of the training.

Article 17.Software deployment

1. Preparation of the deployment program

a. To determine requirements for the deployment: scope, technical environment, operating environment, operating features, number of users.

b. To determine resources, deployment time limit, plan for the organization and implementation and the way of inspection test.

c. For software that is deployed for several places, experimental deployment shall be carried out, summed up partially for deriving lessons from experience before the large-scale deployment.

2. Preparation of solutions and process for the deployment

a. To study deployment solutions: general solutions, solution applicable to each matter, each requirement.

b. To prepare standards for taking over the work and the sample minutes on taking over.

c. To set up deployment process: steps, implementing instruments, procedures need to be completed, examining modes.

3. System installation

a. Operating environment must be in line with technical requirements of design documents.

b. System software, instrumental software, application software shall be installed in accordance with installation guidance.

c. First data: parameters, system data, and conversion of old data

4. Test run

a. The operation and examination of program shall be carried out in practical environments. To reconcile the result with reconciliation system or expected result, to correct errors (if any) and perfect the program.

b. To carry out the official operation when satisfying users requirements. Time for test run shall be determined based on the scale, the completeness of program and users skills.

5. Official operation

a. To determine time, method and steps of implementation

b. Ready to support users and deal with breakdowns

c. To make diary following up the operation of program and the entire system.

Article 18.Management of software configuration

1. Preparing the file for managing configuration of software products

a. To study information of software: list of products, implementation schedules, main points of time and requirements for the configuration management

b. To determine changed stages and time points

c. To determine the list and codes of configuration units of each stage.

d. To prepare a table following up the combination of products

dd. To organize a directory for preservation and delegate access priority to each software that needs managing.

e. To make backup copy under applicable regulations.

2. Controlling the change of product configuration

a. To receive, analyze, assess the content, cost and time for requirements for change implementation.

b. To consider and approve requirements for changes.

c. To make changes to relevant configurations.

d. To determine the number signs of new versions for changed configurations

dd. To update documents recording the changes of configuration and follow up the combination of products.

3. Preserving configuration of products

a. To prepare safe location, environment and conditions for preservation

b. To carry out periodical examination to environment and conditions for preservation.

c. Each version of software shall be preserved at least at 2 different locations for backup

4. Numbering software versions

a. To number main versions or their respective upgraded versions of each issued products.

b. Number sign of versions must be clearly displayed on the program s screen, taken notice in the program and strictly managed to prevent coincidence during the process of deployment and utilization.

Article 19.Operation support after deployment

1. Preparing support plan

a. To study the support demand of users

b. To determine support conditions, resources, equipment ort and support project

c. To stipulate support objectives, scope, result, time, location and support diary.

2. Carrying out the support.

a. To prepare equipment conditions, documents, location and environment for support

b. To acknowledge requirements, analyze, prepare and try settlement solutions.

c. To support, guide the users, follow up and acknowledge settlement results.

d. To record in the book for following up process of support requirement settlement.

3. Consolidating, reporting support results

a. To consolidate files, requirements for support in the reporting period.

b. To analyze arising issues relating to products.

c. To make periodical support report: statistic data, arising issues and proposals relating to products.

Chapter IV

PROCUMENT OF BANKING OPERATION SOFTWARE

Article 20.Procurement of banking operation software

1. To make report "description of system operation and users requirements" in accordance with provisions at Article 12 paragraph 4 of this Regulation to use as a technical document for auction invitation.

2. To compare with technical documents for auction invitation, consider the capability of satisfaction, estimate the volume required to supplement, adjust the software being offered.

3. To cooperate with suppliers to clarify and receive contents of design documents; to determine contents of adjustment and preparation conditions of technical and legal environment before putting the software into operation according to Article 13 of this Regulation.

4. To check and take over products and carry out the operation in accordance with standards provided for in Chapter II and Articles from 15 to 19, Chapter III of this Regulation.

5. Procured software must be supported by the license in line with written agreement on the procurement.

Article 21.Requirements of warranty, maintenance of software

1. Software shall be given a warranty under standards of suppliers

2. In case where units have other demand, Articles on maintenance stages should be agreed upon with supplier in the document on the purchase of, processing hiring of software.

Article 22.Issuance of software

1. Software hired to process, procured must be considered by the information technology specialist body of the unit and comply with technical standards provided for Chapter II of this Regulation; updated with information and preserved in the software stock of the unit.

2. The new issuance or update of operation software versions shall be approved by the Head of unit.

3. To issue in conjunction with the notice: the list and the state of components of issued software and their changes in case of upgraded versions.

Chapter V

IMPLEMENTING PROVISIONS

Article 23.Dealing with violation

Any act of violation of Articles of this Regulation shall be, depending on the seriousness of violation, subject to administrative punishment, compensation for material damages, prosecuted for criminal liability under provisions of applicable laws

Article 24.Implementing responsibilities

The Banking Information Technology Department shall be responsible for guiding, following up and examining the implementation of this Regulation

Article 25.Any amendment, supplement of this Regulation shall be decided upon by the Governor of the State Bank.