Decision No. 1630/2003/QD-NHNN on technical standards for processing and purchasing banking business software

Pursuant to …;

ISSUING REGULATIONS ON TECHNICAL STANDARDS IN THE DEVELOPMENT AND PURCHASE OF BANK BUSINESS SOFTWARE
BANK OPERATIONS

GOVERNOR OF THE STATE BANK OF VIETNAM

Pursuant to the Law on the State Bank of Vietnam No. 01/1997/QH10 dated December 12, 1997 and the Law on Credit Organizations No. 02/1997/QH10 dated December 12, 1997; 02/1997/QH10 dated December 12, 1997;
Pursuant to the Law Amending and Supplementing Certain Provisions of the Law on the State Bank of Vietnam No. 10/2003/QH11 dated June 17, 2003;
Pursuant to Decree No. 86/2002/NĐ-CP dated November 5, 2002 of the Government stipulating the functions, tasks, powers, and organizational structure of Ministries and ministerial-level agencies;
At the proposal of the Director of the Banking Technology Department,

DECISION:

Article 1. Issued along with this Decision are "Regulations on Technical Standards in the Development and Purchase of Bank Business Software."

Article 2. This Decision takes effect fifteen days from the date of publication in the Official Gazette.

Article 3. The Heads of the Office, the Director of the Banking Technology Department, the Heads of Units under the State Bank of Vietnam, the General Directors (Directors) of commercial banks, and the Central Credit Funds shall be responsible for implementing this Decision./.

 

REGULATIONS

TECHNICAL STANDARDS IN THE DEVELOPMENT AND PURCHASE OF BANK BUSINESS SOFTWARE
(Issued together with Decision No. 1630/2003/QD-NHHH dated December 19, 2003 of the Governor of the State Bank of Vietnam)

Chapter 1:

GENERAL PROVISIONS

Article 1: Scope of application

1. These regulations include basic technical standards, procedures for development, purchase, deployment, and operational support for bank business software of the State Bank of Vietnam and credit organizations (hereinafter referred to collectively as units), aimed at unifying the management of the application of information technology in banking activities to achieve high efficiency and asset safety.

2. Software used for research purposes, testing, or localized use at a single location without connection to the common bank business software of the unit does not fall within the scope of these regulations.

3. In addition to these regulations, the leasing, purchase, and procurement of bank business software must comply with state regulations on leasing and purchasing goods and services.

Article 2: Definitions

1. Geological and mineral documents (hereinafter referred to as documents) include geological reports and original documents.

1. A program is a set of instructions written in a specific language and used directly or indirectly on a computer or information processing device to achieve a specific result.

2. Software includes programs, technical documentation, and related data used for the programs.

3. Bank business software is software applied in bank business operations to automate part or all of those operations.

4. Packaged software is software produced in bulk and sold as a complete packaged product.

5. Program module is a portion of a program that is separately written and tested, then combined with other modules to form a complete program.

6. Open software is software that complies with national and international industry standards regarding openness and high compatibility with system changes and business requirements.

7. Software version is a series of numbers attached to the release of a software product. Versions are divided into major versions and upgrade versions; major versions are subsequent versions following the first development and significant changes in the organizational structure and functions of the software; upgrade versions are used during the process of fixing errors and updating emerging requirements.

8. Software usage rights are a legal confirmation of the right to exploit the software according to the rights stipulated by copyright.

9. System is an organized integration of software, equipment, and other related factors according to a certain standard to enhance overall usage efficiency.

10. System design is the work of translating business and user requirements into detailed technical models guiding software development.

11. Configuration is a set of programs, documentation, and data adjusted according to a specific technical requirement.

12. Template is a model representing design, programming, or business process handling ideas, helping to visualize, evaluate, and direct work before proceeding with implementation.

13. Standard program library is a collection of standardized programs intended for shared use and repeated application.

14. Software adjustment is the modification and supplementation of software components to better meet user requirements.

15. Software testing is the work of inspecting and testing software to identify business processing, programming, interface, or interaction errors between program modules and determine the degree to which the software being tested meets the specified requirements.

16. A testing scenario is a set of factors, input data, implementation conditions, and expected results. Testing scenarios are established to meet specific objectives such as testing a program function, system load capacity, user requirements, and other requirements if any.

17. A testing procedure is a set of instructions for establishing, performing, and evaluating the results of one or more testing scenarios.

18. A testing program is a program used to automate the execution of testing procedures. Testing programs may be developed through programming or generated automatically using testing tools.

19. Business analysis and user requirements analysis is the process of understanding and describing business problems, user requirements, their interrelationships, and analyzing the feasibility of those requirements with the application of information technology under specific conditions.

20. Software deployment is the work of researching technical solutions, setting up procedures, organizing training, installation, usage guidance, initialization, data conversion, and putting software into operation.

21. Software warranty and maintenance is the work of managing changes and providing operational support to ensure the accurate, smooth, and safe operation of deployed software.

22. Software configuration management is a tool for establishing, retaining, releasing software products, and systematically controlling their changes.

23. User is the person assigned the task of operating the program to perform tasks within the assigned authority and responsibility.

24. System administrator is the person assigned the task of managing and ensuring the smooth, secure operation of the system.

25. Business software development is the entire process of business analysis and user requirements analysis, system design and analysis, programming, user guide documentation, testing, and packaging software.

Article 3: Software usage rights

Business software used in banking operations must have usage rights according to the provisions of the law. Unauthorized actions such as changing, copying, disclosing design, algorithms, technology, and source code are strictly prohibited.

Article 4: Software upgrade

Software upgrades promptly address program defects, reflect changes in business processes, and replace outdated algorithms and technologies. The time between upgrades shall not exceed the depreciation period specified for the software.

Chapter 2:

BASIC TECHNICAL STANDARDS FOR BANK BUSINESS SOFTWARE

Article 5: Selection of technology and software solutions

1. Effectively meet business requirements, deployable in practice, and capable of long-term use.

2. Ensure business safety and security standards.

3. Comply with open system software design standards.

4. Be appropriate to the technological level, financial resources, and effectively utilize the investment capital of the entity.

Article 6: Safety and Security Requirements

1. Assess potential risks of the system from the system analysis and design phase, classify the level of importance of each component and the entire system.

2. Clearly define and fully implement technical and environmental conditions for installation and operation of safe business activities.

3. Have appropriate contingency plans for handling incidents suitable to the characteristics of business operations regarding maximum allowable downtime and data importance levels.

4. Control and prevent unauthorized access to the system and take timely measures to mitigate any consequences.

5. Control operations, only allowing users to operate according to assigned functions and tasks. Alert for operations that could cause data loss or impact system operations.

6. Implement verification and protection solutions for data integrity and encryption of data at the "Confidential" level or higher when exchanged over networks in the banking industry.

7. Data encryption software and digital signature software must be developed, managed, and used under the "Top Secret" regime in the banking industry.

Article 7: Open Design and Stable Operation

1. Programs designed relatively independently of hardware components, operating systems, databases, and communication systems of the system; parameterize input factors, program setup parameters, and divide into functional modules; capable of expansion and connection with other business software in the future.

2. Run stably, meeting business requirements and handling exceptions properly.

Article 8: User Interface

1. Consistent throughout the program regarding screen layout, color, menu, font, and symbol usage conventions, and consistent methods of input, output, and program execution.

2. Arrange program functions according to scope, job groups, and operational sequence; provide online support and eliminate redundant operations in operation.

3. Warn and prevent accidental errors in operation; do not allow users to perform tasks beyond their assigned authority.

Article 9: Interface with Other Business Software

1. Continuously connect with related business software; except for testing purposes, avoid duplication in data collection, transmission, processing, and storage.

2. Use unified codes issued for the same business object reference.

3. Ensure security in connections, preventing unauthorized access or illegal interference with data on either side.

Article 10: Technical Documentation

1. Technical documentation must accompany the program:

a) Configuration of hardware equipment, network, operating system, database, and other equipment used for the operational environment and backup environment of the software;

b) Installation and operation guidance for the program;

c) Guidance for storing and restoring the program and database.

2. Initial issued documentation and subsequent updated versions must be stored fully and conveniently for reference when needed.

Chapter 3:

DEVELOPMENT, DEPLOYMENT, AND OPERATIONAL SUPPORT FOR BANK BUSINESS SOFTWARE

Article 11: Planning, Inspection, and Handover of Work Results

1. Develop plans for each stage of design, construction, deployment, support, and operation of the software, and review and approve results upon completion.

2. The inspection plan and report include the following contents: scope, objectives, time, human resources, costs, and other implementation conditions; milestones, inspection standards, and results obtained.

Article 12: Business analysis and user requirements

1. Business survey:

a) Study business documents: regulations, procedures, guidance materials, and other documents provided by users.

b) Compile a list of issues and questions to be surveyed.

c) Conduct practical business activity surveys and interview users.

d) Gather materials and write a survey report.

2. Business analysis:

a) Analyze business requirements, organizational characteristics, technical environment, legal environment, and user characteristics.

b) Develop documentation for modeling business process flows, data streams, and information-bearing entities.

3. User requirement analysis:

a) Develop documentation describing and categorizing functional requirements, operational environments, operational requirements, and other requirements from the user's perspective.

b) Analyze the feasibility, consistency, and rationality of requirements; determine priority levels, criteria, and conditions for satisfying requirements.

c) Create templates if necessary.

d) Communicate with users, eliminate unreasonable or unfeasible requirements; resolve conflicting requirements and research additional new requirements if needed.

4. System operation description and user requirement specification:

a) Develop documentation describing the architecture and operations of the current and future systems: operational processes, actions, business constraints, scenarios, and solutions.

b) Develop documentation specifying user requirements: descriptions of functional requirements, interfaces, data organization, operations, equipment requirements, and other requirements from the technical staff's perspective.

c) Confirm the results with users.

5. Business personnel are responsible for providing complete and timely business documents, responses to survey requests, and confirming the accuracy of the business analysis report if requested.

Article 13: Software system analysis and design.

1. Study design requirements:

a) Classify and describe requirements: identify standards, procedures, and guidelines for design; study similar problems, reuse existing designs, and determine necessary tools.

b) Consider the completeness and rationality of functional requirements and their level of implementation, the legality of legal requirements; handle unclear and conflicting requirements.

2. Overall design:

a) Study user requirement documentation and determine basic system architecture elements such as technical models, operations, database organization, and program organization; aspects of security, confidentiality, management, and operations, and create templates if necessary.

b) Select methods, standards, and design tools.

c) Develop overall design documentation for programs and data.

d) Consider the feasibility of the established documentation for detailed design and programming phases.

3. Detailed design:

a) Design user interface screens, report templates, processing algorithms, and interfaces with other business functions; data safety and security levels, and other design contents.

b) Choose databases, programming languages, tools, and related technologies for building, organizing, and deploying business software.

c) Develop detailed technical documentation for user requirements and operational environments for business software.

d) Review, evaluate design documents, feasibility, and readiness for programming.

Article 14: Program writing

1. Programming code standards:

a) Program comments: general description, revision history, reviser, reviewer, and content of revisions at the beginning of the program; explanations for complex or easily confusing code segments or to explain program processing.

b) Present the program code structure clearly and hierarchically.

c) Uniformly name objects throughout the program. Names should be meaningful, reflect overall or local scope, and distinguish between different types of objects. Naming conventions and file types should match the content and standards of the software tool.

2. Design and program common library modules.

3. Program and integrate functional modules:

a) Program system modules according to the design documentation prepared in previous stages; test, review, and integrate into a complete program.

b) Set up the testing environment, test individual modules and the entire program according to the design documentation requirements.

4. Write system function documentation:

a) Overall software functionality built.

b) Main system functions: structure diagrams, flowcharts, system interfaces, and data streams.

c) System requirements: supporting data, equipment configuration, and operational environment.

d) Software structure: source code libraries, execution programs, software support programs.

5. Write installation tools, operating manuals.

Article 15: Test and adjust software.

1. Develop a testing plan:

a) Testing requirements and product evaluation criteria.

b) Scope of testing: work limits, manpower, key milestones in the testing schedule, duration, cycles, and repeated testing steps.

c) Testing methods.

d) Testing resources and environment: number of people and skills, hardware and software testing environment, network infrastructure, and testing tools.

2. Build testing scenarios:

a) Compile a testing checklist.

b) Develop testing situations for normal and abnormal system, environmental, and program operation cases.

c) Develop testing procedures including start and end conditions, steps to follow, and necessary testing data.

d) Testing criteria: overall assessment, performance, load capacity, and abnormal situation handling.

3. Conduct integrated testing:

a) Set up a testing environment simulating actual operational conditions of business software.

b) Test according to scenarios, record results and detected errors.

c) Handle errors that occur and retest after resolution.

4. Review and evaluate the results of the inspection:

a) Analyze errors based on frequency, severity, time to fix, and propose handling measures.

b) Evaluate the pass rate through inspection.

c) Prepare a comprehensive inspection report, assess the software's compliance with requirements, and its operational deployment capability in practice.

5. Inspection staff must be independent from programming staff, thoroughly understand system design documents, operational requirements, and be responsible for the quality of the inspected product.

Article 16: Training and instruction

1. Training and instruction requirements:

a) Conducted before or concurrently during the software implementation process.

b) Targeted appropriately.

c) Training environment simulates actual operational conditions of the business.

d) Adequate operational documentation.

đ) Inspect and issue certificates allowing the use of software for participants in courses requiring high operational skills.

2. Implementation of training:

a) Develop a training program: content, format, requirements, and implementation conditions.

b) Prepare the environment, materials, data, and instructors.

c) Conduct centralized or on-site training.

d) Summarize and evaluate the results of organizing training.

Article 17: Software Deployment

1. Develop a deployment plan:

a) Determine deployment requirements: scope, technical environment, operational environment, operational characteristics, number of users.

b) Identify resources, deployment timeline, organizational implementation plans, and acceptance procedures.

c) For software deployed at multiple points, it must undergo pilot deployment, preliminary summary, and lessons learned before full-scale deployment.

2. Develop solutions and deployment procedures:

a) Study deployment solutions; general solutions, solutions for specific issues and requirements.

b) Establish acceptance criteria and sample acceptance records.

c) Develop deployment procedures: steps, tools, required procedures, and testing methods.

3. System installation:

a) Operational environment meets technical requirements of design documents.

b) Install system software, tool software, and application software according to installation guidelines.

c) Initial data: parameters, system data, data conversion.

4. Run tests:

a) Operate and test programs in actual environments. Compare results with control systems or expected outcomes, correct errors if necessary, and refine the program.

b) Officially operate when user requirements are met. Testing duration depends on the scale, completeness of the program, and user skills.

5. Official operation:

a) Establish timing, methods, and steps.

b) Be ready to support users and handle incidents.

c) Maintain logs tracking program and system activities.

Article 18: Software Configuration Management

1. Establish configuration management files for software products:

a) Research software information: product list, schedule, key milestones, and configuration management requirements.

b) Determine phases and change milestones.

c) Determine configuration component lists and codes for each phase.

d) Create a product interrelation tracking table.

đ) Organize directory storage and access permissions for each managed software.

e) Backup storage as prescribed.

2. Control changes to software configurations:

a) Receive, analyze, and evaluate the cost and time required for change requests.

b) Review and approve change requests.

c) Implement changes to observed components.

d) Assign new version numbers to changed components.

đ) Update configuration change documentation and track product interrelations.

3. Store software configurations:

a) Prepare secure storage locations, environments, and conditions.

b) Periodically check storage environments and conditions.

c) Each software version must be stored in at least two different locations as backups.

4. Version numbering of software:

a) Assign main version or update version numbers to each released product.

b) Version numbers must be clearly displayed on the program screen, noted within the program, and strictly managed to avoid confusion during deployment and use.

Article 19: Post-deployment Operation Support

1. Develop support plans:

a) Study user support needs.

b) Determine support conditions, resources, equipment, and methods.

c) Specify support goals, scope, results, timelines, and log entries.

2. Implement support:

a) Prepare support equipment, materials, locations, and environments.

b) Record requests, analyze, develop, and test solutions.

c) Support and guide users, monitor, and record solution outcomes.

d) Log progress in resolving support requests.

3. Compile and report support results:

a) Compile support case files and requests for the reporting period.

b) Analyze issues arising related to the product.

c) Prepare regular support reports: statistical data, emerging issues, and recommendations related to the product.

Chapter 4:

PROCUREMENT OF BANK BUSINESS SOFTWARE

Article 20: Procurement of bank business software

1. Prepare a "system activity description and user requirement specification" report in accordance with Article 12 Clause 4 of this Regulation as bidding technical documentation.

2. Compare with bidding technical documentation, assess the ability to meet requirements, estimate additional and adjustment volumes needed for offered software.

3. Coordinate with suppliers to clarify and accept design document contents; determine adjustment contents and environmental preparation conditions before software operation as stipulated in Article 13 of this Regulation.

4. Inspect, accept, and deploy software operations in accordance with standards set out in Chapter II and Articles 15 to 19 of Chapter III of this Regulation.

5. Purchased software must have appropriate usage rights consistent with the purchase agreement text.

Article 21: Software warranty and maintenance requirements

1. Software warranty according to supplier standards.

2. If the entity has requirements, maintenance phase terms must be agreed upon with the supplier in the software purchase, lease, or processing contract.

Article 22: Software Release

1. Software subject to outsourcing or procurement must be reviewed by the specialized information technology department of the unit to ensure compliance with technical standards set forth in Chapter II of this Regulation; update information and store in the unit's common software repository.

2. Issuance of new versions or updates of business software must be approved by the head of the unit.

3. Issuance accompanied by notification: list and status of components of the issued software and changes if it is an updated version.

Chapter 5:

IMPLEMENTING PROVISIONS

Article 23: Handling Violations

Any violation of the provisions of this Regulation shall be subject to administrative handling, compensation for material damage, or criminal liability追究，依照法律规定。

Article 24: Responsibility for Implementation

The Banking Information Technology Department is responsible for guiding, monitoring, and organizing inspections of the implementation of this Regulation.

Article 25: Any amendment or supplementation to this Regulation shall be decided by the Governor of the State Bank of Vietnam./.