|
Table of Contents
|
General Information
Purpose
The purpose of this document is to describe a requirement for a banking system for use by any small credit union. The proposed banking system is intended to reside on a hosted web server and interact with several external systems, including amongst others, a host bank for external ACH style payments, any accounting system of the credit union's choosing with which to keep track of the the business of the credit union, and other external systems such as SMS gateways etc.
The system keeps track of all persons viz customers, staff, and related persons (required under various legislation such as FICA1 as well as all address and other ancillary information. It keep detailed account of all transactions for all accounts by all customers. It keeps accurate audit trails of each and every action, by all users and all system/automated
activities.
The security of the system must be such that a breach of security would avail little and in the unforeseeable instance that a system comprise occurred that it be contained to that single instance of breach and not be extensible to other areas of the system.
The system must provide integration interfaces for other systems (automated and manual) and all system boundaries must be monitored and all transactions crossing these boundaries requires an extra level of authentication/intervention.
The system will provide reporting, both automatically and on demand, and such reports must comply with statuary and regulatory requirements, as well as provide statistical insight into consumer behavior. Security and audit reporting must also be produced.
The system has a rolling archive, backup and off-site replication capability. A restore and archive retrieval must be demonstrable before commissioning the system live.
Scope
The scope of this document is to describe the three anticipated phase of development requirements are are necessary to achieve a sustainable and viable Community Bank solution.
Project References
Click here for project related links and references.
Proposed System
Background
A clay model of the proposed solution was built and hosted at www.gautengsavers.co.za for Southern Cross Community Bank. It had limited functionality but served as a proof of concept for several key concepts - such as the use of two factor authentication with a call centre.
Functionality Required
The primary functionality required fro the sytem is as follows:
- Transaction Engine
- customer accounts
- customer internet banking
- customer cellphone (sms based) banking
- assisted banking (by internet enabled agent or call centre)
- savings accounts
- Lending Engine
- Loan Accounts
- current accounts
- interest generation
- fee generation
- statement generation (PDF, printed/emailed/hosted)
- mini-statement generation
- notifications (email/ SMS /Internet)
- compliance reporting (refer to SACCOL compliance requirements)
- credit union performance dashboard for members to see real-time performance metrics
- audit trails
- transaction batch import/export
- manual batch entries
- extract for upload into accounting system (Interest Charged, Fees Charged, Total Loan Assets by asset class, Total Deposit liabilities, Total Customer Shareholding by value , etc as per the control accounts required by SACCOL)
- Upload from banking system (bank account entries) and auto-reconciliation of these items.
- Export of 3rd party payment instructions (in ACH file or in report format for manual execution)
Development Strategy
The development strategy is to evolve the solution concentrically around a core set of capabilities, hence the contents of the proposed development phases. The strategy is to spend more effort on getting to the underlying framework developed and to ensure that it meets the design criteria of being asynchronous, 24x7x365, configurable, upgrade-able, maintainable, usable and easily extensible. Because the system is to be data-centric the chief vulnerability of this approach is that a design flaw can result in a change in underlying data structures - therefore the strategy is to put the design in the data and not in the data-structure.
Use of all open source components is assumed from the start. Platform independence is desirable but is outside the scope of this project.
Phases
Phase 1 : Core Banking
- Internal Transactional and Savings Only (Internet/SMS)
- This is a functional system but limited to savings accounts only.
- Interest Paid Calculations
- No ACH transactions
- Bank & EasyPay reconciliation for deposits
- Accounting System Integration
- No Reporting
Phase 2 : Core Lending
- Internal Transactional, Savings and Loans (Internet/SMS)
- Credit Committee available process facilitated by online loan creation, scoring etc
- Interest Paid and Earned Calculations
- No ACH transactions
- Own Branch transactions including Cash Withdrawal
- Required Reporting Added
Phase 3 : Core Interbank
- External Transactional Capability Added (Internet/SMS/POS/ATM)
- This is only a functional extension but no new account types need be added
- Full ACH integration via sponsoring bank
- Reporting Extended
Phase 4 : Core Cards
- Private Label Card Issuing System
- CMS for Private Label cards
- Functional Requirements Document
- Authorization Host
- Card Issuing Mechanism for outsource card production and input-file upload to CMS
- No PIN, Signature Based only
- Allow for signature capture at Branch
Phase 5: Core Cryptography
- Introduction of PIN Based Card Transactions
- HSM integration
- PIN encoder Module -eg on Pinpad
- Full ISO8583 support on CMS
Phase 6 : Core Security
- Real time replication
- Automated backup and restore
- Automated back office audits
- Automated exception reporting
Summary of Impacts
The impacts and associated costs/benefits of the proposed system on the existing development, organizational and operational environments of the user, and project are as described here.
Organizational Impact
The key organizational impact being aimed for are the following:
- minimal internal Information Technology infrastructure needed therefore every single part of the credit union's banking business must be do-able via a web interface.
- easily and cheaply scalable technology that can grow at any pace inline with the natural organic growth of any credit union will mean that there is no barrier to entry for any credit union to utilize community banker.
- automated and built-in audit functions with system enforced best practices will mean that members can be more confident that their elected union officials and appointed management will not be able to easily act in an inappropriate or fraudulent manner.
- automated back office processes and automated reporting will ensure that important administrative tasks are never neglected substantially reducing the operational effort involved in establishing and running a credit union.
The entire design and development philosophy must be underpinned by the principle of automation. The question to be asked at each stage of design and development is –
“If it is not automated then why not?”
Operational Impact
Development Impact
Assumptions & Constraints
DETAILED SPECIFICATIONS13
Detailed Functionality
Savings Accounts
Items 2 .. n+1
Interest and Service Fees
41 Specific Performance Requirements13
411 Accuracy and Validity13
412 Timing13
413 Capacity Limits13
42 Detailed Functionality14
421 item one14
422 item two14
423 Credit Union Dashboard14
43 Input and Output14
44 Failure Contingencies15
Functional Requirements Specification Page iv
5 ARCHITECURE AND DESIGN17
51 System Description17
52 System Functions17
53 Flexibility20
6 OPERATIONS22
61 Hardware Infrastructure22
611 Hosting Hardware22
612 Hardware Security Module(s)22
613 Encrypting Pin Pad(s)22
62 Software Environment22
63 Operating Procedures22
631 Daily Operations22
632 Weekly Operations23
633 Monthly Operations23
634 Annual Operations23
64 Communications Requirements23
641 Communications Overview23
642 Communications Hardware23
643 Communications Software24
65 Interfaces24
66 Legal and Standards Compliance25
661 International Standards25
662 Generic Legal Compliance25
663 South African Legal Compliance26
67 Failure Contingencies28
671 Restart/Recovery28
672 Other Contingencies28
68 Assumptions and Constraints28
7 SECURITY30
71 Background Information30
72 Control Points, Vulnerabilities, and Safeguards30
721 Control Points30
7211 Input Control Points30
7212 Process Control Points30
7213 Output Control Points30
722 Vulnerabilities31
723 Safeguards31
7231 Administrative Safeguards31
7232 Physical Safeguards31
7233 Technical Safeguards31
73 System Monitoring and Auditing32
731 Journalizing32
7311 Triggering Criteria32
7312 Identification Information32
7313 Application Data32
7314 Journal Use32
732 Audit Trail32
7321 Transactions Back to Original Source Documents32
7322 Transactions Forward to Summary Totals32
Specification Revision Sheet | Applicable Licences | Common Acronyms
