integrated cross-border foreign exchange reporting ... · integrated cross-border foreign exchange...

INTEGRATED CROSS-BORDER FOREIGN EXCHANGE REPORTING

SOLUTION

for The South African Reserve Bank

Enclosure A - Enterprise Architecture Guidelines

South African Reserve Bank i-CFERS RFP – Enclosure A – Enterprise Architecture Guidelines

Table of Contents 1 Architecture Standards ......................................................................................................................... 3

1.1 Classifications ............................................................................................................................. 3

1.2 Information Security .................................................................................................................... 3

1.3 Data Management ........................................................................................................................ 4

1.4 Collaboration and Electronic Workplace .................................................................................. 5

1.5 Applications ................................................................................................................................. 6

1.6 Networking and telecommunications ........................................................................................ 7

1.7 Platforms and Storage ................................................................................................................ 9

1.8 Systems Management ............................................................................................................... 10

2 Business Architecture ......................................................................................................................... 12

2.1 FNSD Introduction and Background ....................................................................................... 12

2.2 Administration & Risk Management Division ......................................................................... 21

2.3 Compliance & Enforcement Division ...................................................................................... 22

2.4 Analysis & Information Flow Division ..................................................................................... 23

2.5 ADLA Supervision Division ...................................................................................................... 25

2.6 Inward Listing & Institutional Reporting Division .................................................................. 26

2.7 Financial Operations Division .................................................................................................. 27

3 Application Architecture Definition ................................................................................................... 29

3.1 FNSD Application Eco-System ................................................................................................. 29

3.2 FNSD Application Eco-System Architecture Transition Roadmap ...................................... 35

3.3 Extended Baseline Application Architecture Definition ........................................................ 41

3.4 Application Integration – Data Flow Diagrams ....................................................................... 57

4 Files and Transactional Volumes ....................................................................................................... 64

SARB CONFIDENTIAL INFORMATION


1 Architecture Standards

1.1 Classifications Each technology and product listed in the tables below is assigned a classification of Standard Technology (S), Preferred Technology (P) or Guidance Information Only (G).

• Standard Technology: A technology/product that is in place in most or all instances. It should be the first choice when selecting a technology or product, barring mitigating circumstances (such as plans to upgrade it to the next version, for example). It is a product actively supported by the Business Systems and Technology department.

• Preferred Technology: A technology that is the target product of a planned upgrade or transition. While not widely deployed, it will become the future Standard Technology. Support from BSTD exists, but may be immature or in transition.

• Guidance Information Only: A technology for which no clear standard exists due to the role or pervasiveness of the technology or product in the Bank, or due to immature or fluctuating market conditions.

1.2 Information Security This section includes technologies related to application, data, network, server and desktop client security.

Table 1: Information Security Standards

Information Security Technology or product S/P/G Remarks

Enterprise Firewall Checkpoint FW-1 NG R7.6 Cisco ASA5510

S

G

Perimeter firewall (HO & AS) Network firewall between Bank and SARB_link networks

Personal Firewall Symantec Endpoint Protection S Laptops and devices beyond the network perimeter

Distributed Denial of Service (DDoS)

Arbor Pravail APS S Deployed at Head Office and Alternate Site

Virtual Private Network (VPN)

Checkpoint VPN-2 Secure Client

S All laptops and desktops connecting vie public networks to computing resources on Bank’s network

Anti-virus for E-mail Cisco IronPort Appliance SOPHOS AV Software

S

S

Deployed at Head Office and Alternate Site

Anti-virus for other web traffic i.e. http, ftp, etc.

Bluecoat Proxy AV appliance McAfee AV software

S

S


Anti-virus for servers, gateways and desktops

Symantec Endpoint Protection S Mandatory for all servers and gateways attached to the Bank’s network

Network Access Cisco Access Control Server S Deployed at Head Office and



Information Security Technology or product S/P/G Remarks Controller (ACS) Alternate Site

Threat Management Checkpoint IPS Microsoft Threat Management Gateway (TMG) (UAG) FPE – MS Forefront for Exchange

S

G

Deployed at Head Office and Alternate Site MS Exchange SARB Internet website

Internet Content Filtering and Traffic Monitoring

Bluecoat Proxy SG Bluecoat Web Filter

S

S


Public Key Infrastructure SSL and users certificates

Verisign Entrust

SSL Certificates for SAMOS, Oracle eBS, Internet Banking, etc.

E-mail Security Cisco Ironport S Actively utilised Internally and by 3rd parties

Endpoint Encryption Sophos S Laptops & Removable media

1.3 Data Management This section includes technologies related to databases and data warehousing, data management, file formats, messaging and data interfaces.

Table 2: Data Management Standards

Data Management Technology or product S/P/G Remarks

Data Warehousing and Mining

Oracle Discoverer OBIEE Microsoft BI

G S G

Messaging/Routing Service

IBM WebSphere Message Broker

S

Enterprise Integration (Middleware)

IBM WebSphere suite S

Domain Integration Oracle SOA MicroSoft Biztalk GlobalScape FTE

G G G

ERP System only SARBDEX Environment only

Relational Database Management Systems (DBMS)

Oracle 11g Enterprise Edition MS SQL Server 2008 Enterprise Edition R2 Oracle 11g Standard Edition MS SQL Server 2008 Standard Edition Sybase

S S

S P

G

Enterprise and large-scale systems with high capacity, complex design, and/or high volume transactional requirements Mid-scale systems with moderate capacity and/or transactional volume requirements



Data Management Technology or product S/P/G Remarks Oracle 11g Named Users MS Access IBM DB/2

G

G

S

Small-scale systems with small to moderate capacity, design complexity, and/or transactional volume requirements. Typically workgroup systems. The use of MS Access is largely discouraged. Seek guidance from Database Administrators. Mainframe environment

1.4 Collaboration and Electronic Workplace This section includes technologies and products related to the automation of basic office productivity tasks, support the creation and management of knowledge, person-to-person communication, and real-time and asynchronous collaboration.

Table 3: Collaboration and Electronic Workplace Standards

Collaboration & Electronic Workplace

Technology or product S/P/G Remarks

Collaboration MS Sharepoint 2010 SP1 S

Document Management MS Sharepoint 2010 SP1 IBM Lotus e-Docs

S G

Being discontinued

E-mail • SMTP • Mobile

MS Exchange with Outbound SMTP Active Sync Blackberry Enterprise Server for MS Exchange

P

S

S

Supported with Smartphones

Instant Messaging (IM) and Presence

Cisco JABBER S

Web Conferencing Cisco WebEx

Room-based Video Conferencing

Cisco TMS S

Web Portal MS Sharepoint 2010 SP1 S



1.5 Applications This section is focused on the software infrastructure supporting the design, development, deployment, and operation of custom and packaged applications. This includes both the software supporting individual applications and the software supporting system-to-system integration.

Table 4: Applications Standards

Applications Technology or product

S/P/G Remarks

Enterprise Resource Planning (ERP) System

Oracle E-Business Suite

S Production implementation date was May 2008. The application/s are accessible from any site or client VPN within the corporate network. Current access methods include: Internet Explorer and terminal server. As currently configured Oracle has no automated internal or external data feeds. Oracle is running with the following instances: • PROD – Production

environment • DEV – Development

environment • QA – Quality assurance • UAT –Special projects

environment • TST – Daily clone environment.

Basket of Tools

MS Office Professional 2010 MS Internet Explorer 8 MS Outlook 2010 Winzip 16 Acrobat Reader 10 Adobe Flashplayer 10 ActiveX Java 6 Update 21 IBM Tivoli Endpoint Manager Symantec Endpoint Protection v12

P

S P

S S S S S S

All new desktops being implemented. Excludes MS Access Required for access to ERP system

Risk Management Cura G

Web Development MS Visual Studio S



Applications Technology or product

S/P/G Remarks

tools 2008 DreamWeaver CS3 WebTrends Analytics 8.5

S

Computer Graphics Adobe Illustrator CS3 Adobe Photoshop CS3 Adobe InDesign CS3

S

S

S

1.6 Networking and telecommunications This section is focused on the communication infrastructure for the distributed computing environment. It consists of logical elements (structure, topology, bandwidth, management), physical hardware components (wiring, LANs, switches), carrier services (frame relay, leased channels, ATM), and protocols (access routing, naming).

Table 5: Networking and Telecommunications Standards

Networking & Telecommunications


Cable Media KRONE UTP CAT-6a Copper 10 MultiMode Fibre (MMF)

S

S

Horizontal cabling Blown Fibre for backbone cabling Tight Buffer cabling for other short-distance applications

Patch Panels KRONE Highband S

Workgroup Connectivity Cisco 3750 V2 and Cisco 3750x Series

S 10/100/1000 Mb/s Ethernet to the desktop

Network Core Cisco 6500 Series Cisco 4500 Series

S

S

Gigabit Ethernet backbone for Head Office and Alternate Site Gigabit Ethernet backbone for Branches

Network and Transport Layer

TCP/IP

S

Address Management DHCP S On MS Server 2008 SP1

Network Routing Protocol

OSPF G

Wireless Access Points Cisco Aironet S

Network Time Service NTP G Follow IT Guidance

System Monitoring and Control

SNMPv1 G Follow IT Guidance

Naming Service Windows Server 2008 (Internal) S



Networking & Telecommunications


• DNS

Directory Service MS Active Directory IDM

S On MS Server 2008 SP1 User Password Self-help

PBX Alcatel 4400

S

P

All Alcatel TDM PBX’s to be replaced with Cisco VoIP technology towards the end of 2014.

Dealer Communication British Telecom (BT) S BT Dealer communication System – only implemented at Head Office

VoIP Cisco Unified Communications Manager (CUCM) 9.1 Cisco 3900 VoIP Gateway

S Deployed at Head Office and Alternate Site

Desktop Sets • Tier 1

• Tier 2 • Tier 3

Wi-Fi / DECT Conference Units Intercom

Alcatel Manager/Secretary Cisco 7962 Alcatel 4029 Cisco 7942 Alcatel 4003 Cisco 7911 Alcatel DECT 300 Cisco 793 Cisco 7925 Cisco 7937 Cisco 7906

S P

S P

S P

S P

S

G

Specialised requirements only – Switchboard and Manager/Secretary configurations

Telephone Management System (TMS)

Galactrix TMS S

Voicemail • Alcatel Platform • Cisco Platform

Galactrix Cisco Unity

S S

Voice Logging/recording Weston Voice Logger S



1.7 Platforms and Storage This section include technologies and products related to client device hardware and operating systems, server hardware and operating systems, storage devices, data backup and recovery solutions and configuration management.

Table 6: Platforms and Storage Standards

Platforms & Storage Technology or product S/P/G Remarks

Desktops Dell Lenovo WYSE

S

P

S

Follow BSTD guidance New form-factor with integrated cameras ideally suited for UCC Thin Client / Virtual Desktop

Laptops Lenovo Apple MacBook

S

G

Follow BSTD guidance

Server Hardware IBM Bladecenter H Chassis IBM Bladecenter HS21 IBM RS/6000 Rack Model T42 IBM Power 770

S S G G

Enclosure Wintel Servers Enclosure AIX servers

Mainframe Hardware IBM zSeries S For Payment System

Desktop/Laptop Operating Systems

Windows XP Professional SP3 Windows 7/8.1

S

P

All new desktop PCs and Laptops unless there is a valid reason for deviation

Server Operating Systems

Windows Server 2003 Windows Server 2008 R2 Enterprise IBM AIX v6.1 vSphere v5.0 SUSE Linux Sun/Oracle Solaris Netware 6.5

S P G S G S

SP2 SP2 ERP and SAA environments only Virtual Server OS Follow BSTD Guidance Follow BSTD Guidance

Smartphone and Tablet Computer Operating Systems

IOS Android Blackberry Windows

G G G G

Dependent on the Smartphones and/or Tablet specified by the relevant SME

Data Backup & Recovery • Backup &

Recovery software

• Backup and Recovery Hardware

IBM Tivoli Storage Manager (TSM) ARCserve IBM 3592 IBM TS1040 Ultrium 4 Tape Drive IBM Ultra Scalable Tape Library

S

S S S

For guidance visit IT Network Backup Procedures Mainframe Tape backup Open Systems Backup Open Systems Backup




Data Storage IBM XIV Storage System IBM StorWize V7000 EMC DMX3

S S S

Open Systems Open Systems Mainframe

Storage Area Network Brocade DS-5100B S Open System and Mainframe environment. Refer to specification from relevant SME

Smart Phones Samsung Galaxy Apple iPhone Nokia Lumina HTC One Sony Xperia and associated software suites

S

S G G G S

Requires specific configurations effecting user and enterprise gateways

Tablet Computers Apple iPad Samsung Galaxy Tab Blackberry Playbook Lenovo

S G G G

Refer to specification from relevant SME

Multi-Function Devices Konica Minolta S Refer to specification from relevant SME in BSTD

Printers & Plotters Lexmark, HP & Epson G Refer to specification from relevant SME in BSTD

Projectors Epson, NEC, BenQ, Acer G Refer to specification from relevant SME in BSTD

1.8 Systems Management This section include technologies and products related to client device hardware and operating systems, server hardware and operating systems, storage devices, data backup and recovery solutions and configuration management.

Table 7: Systems Management Standards


Data Storage Management

IBM Tivoli Storage Manager S Follow BSTD guidance

Network Management Cisco Lan Management Solution (LMS)

S

Exchange, Sharepoint and UAG

Opsman S

Software Change Management

Endevor Serena Dimensions

S S

Desktop Operating Windows XP Professional SP3 S



Platforms & Storage Technology or product S/P/G Remarks Systems

Windows 7

P All new desktop PCs and Laptops unless there is a valid reason for deviation

Server Operating Systems

Windows Server 2003 Windows Server 2008 IBM AIX v6.1 vSphere v5.0 SUSE Linux Sun/Oracle Solaris

S P G S G S

ERP and SAA environments only Virtual Server OS Follow BSTD Guidance Follow BSTD Guidance

Data Backup & Recovery • Backup &

Recovery software

• Backup and Recovery Hardware

IBM Tivoli Storage Manager (TSM) IBM

S

S

For guidance visit IT Network Backup Procedures Tapes

Data Storage IBM XIV Storage System IBM StorWize V7000

S S

Mobile devices Blackberry Blackberry Desktop Software v4.2 Apple iPhone 4 iTunes 10 Samsung Galaxy Tab Apple iPad3

S

S

G G S

Requires specific configurations effecting user and enterprise gateways



2 Business Architecture This section of the document details the organisational structure and functions of the Financial Surveillance department, the mandate upon which they perform and its responsibilities. This document will not replace the existing operational and business documents but will be used as an additional document to complement existing documentation.

2.1 FNSD Introduction and Background

2.1.1 Mandate of the FNS Department

The Financial Surveillance department is responsible for the administration of exchange controls in South Africa under the authority that is delegated to the SARB by the Minister of Finance. Exchange Control Regulations are the legal provisions that limit the extent to which South African residents and companies may transfer funds abroad. Policy decisions on exchange controls rest with the Minister of Finance. The policy is determined by the Minister of Finance and the SARB. Therefore the SARB merely acts as an adviser to the Minister of Finance and as an implementer of exchange control policy decisions. The Minister of Finance has, therefore, delegated to the Governor and/or a Deputy Governor, as well as to the Head of the Financial Surveillance Department (and to other officials in the department), all the powers, functions and duties assigned to and imposed on the Treasury under the Exchange Control Regulations (with certain exceptions). The Bank's Financial Surveillance Department is, accordingly, responsible for the day-to-day administration of exchange controls.

The Minister of Finance has also appointed certain banks to act as Authorised Dealers in foreign exchange. This appointment gives these banks the right to buy and sell foreign exchange, subject to conditions and within limits prescribed by the Financial Surveillance Department. Authorised Dealers are not agents for the Financial Surveillance Department, but act on behalf of their clients. Their function is to assist the Financial Surveillance Department in administering exchange control. Rulings issued by the Financial Surveillance Department, set out the authorities granted to Authorised Dealers and the rules and procedures to be followed by the Authorised Dealers in dealing with day-to-day matters relating to exchange control.

Authorised Dealers in foreign exchange with limited authority including Bureaux de Change are authorised by National Treasury to deal in foreign exchange for the sole purpose of facilitating travel related transactions.

Authorised Dealers and Authorised Dealers with Limited Authority are required to report all cross border foreign exchange transactions to the FNS department. These transactions are being reported through the Financial Surveillance Reporting System.

The mandate of the FNS department includes the below:

• Implementing exchange control policy and administering the provisions of the exchange control regulations;

• Appointing Authorised Dealers in foreign exchange with limited authority (ADLAs); • Ensuring compliance by ADLAs with anti-money laundering control measures in terms of the

Financial Intelligence Centre Act; and • Collecting, analysing and disseminating information on cross-border flows.



2.1.2 Business model of the FNS Department

Below figure depicts the high level business model of the FNS Department.

Figure 1: FNSD Business Model

Financial Surveillance Department 1) / Key drivers

ADLA Supervision

Administration & Risk Management

Analysis & Information flow

Compliance & Enforcement

Financial Operations

Inward Listing & Institutional

Reporting

IT / Information Systems

• FinSurv Reporting System (Core System)

• Apex (FinSurv Reports)

• Foreign Loans System

• Foreign Investment Systems

• Imports Verifications Sytems

• Online Risk Manager

• PIRS• Sharepoint

2) Value Chain

& Reporting Obligations to:• FIC• National

Treasury• SARS• Research

Department• Financial

Markets Department

• Ad-hoc Stats to IMF

3) Influencing factors

Regulations

• South African Reserve Bank Act, 1989 (Act No.90 of 1989)

• Currency and Exchanges Act, 1933 (Act No. 9 of 1933)

• Exchange Control Regulations, 1961 as amended

• The Financial Intelligence Centre Act, 2001 (Act No.38 of 2001)

Services / Mandate

• Analyse trends and identify risks associated with currency flows in and out of the country and to respond appropriately;

• Shift from a transactional-based approach of exchange control to a risk-based prudential approach, based on foreign exposure;

• Increase the number of third-tier ADLAs and monitor the number and value of transactions they process;

• Contribute to the development of over-the-counter (OTC) market regulations;

• Enhance quality of cross-border information;

• Improve processes on applications, information management and analytics

• Influence policy on capital outflows;

• Develop and propose a new legislative framework

Objectives



2.1.3 Organisation Structure of the FNS Department

The FNS department compromises of six divisions. Certain divisions are divided into sections which performs distinct functions for the division. Section 3 of this document explains in detail the distinct functions of each divisions and sections. The FNS divisions are being depicted in the diagram below:

Figure 2: FNSD Divisions and Sections

Administration & Risk Management Division

Compliance & Enforcement Division

Analysis & Information Flow Division

ADLA Supervision Division

Inward Listing & Institutional Reporting

Financial Surveillance Department

Risk Management

Investigations

Systems Development

Information Flow

Trade Exports & Imports

Debt Management & Exception Reporting

Exception Reporting

Analysis

Administration

Typist Section

Correspondence Receiving Section

Correspondence Dispatching Section

Budget, Strategy,

BCP, Logistical Support & Staff

Staff Section

Correspondence &

Typing Service

Applications & Inspections

Collective Investment

Schemes and Retirement Funds

Investment

Managers and Retirement Funds

Long Term Insurers

and Retirement Funds

Financial Operations Division

Strategic Risk

Management and Compliance

Operational Risk Management

Specialised Risks

and Internal Audit Liaison



2.1.4 Core Processes of FNS Department

Core Processes Objective of the Core Process Divisions Responsible Sub activities

1. Process and adjudicate foreign exchange applications

• To ensure that applications receive the appropriate response in accordance with Exchange Control policy.

• To initiate a process for the recoupment of capital, and report contraventions to law enforcement agencies (including airport cases and advance fee fraud) and do regularisations and take enforcement actions against ADLAs

• ADLA Supervision Division;

• Analysis and Information Flow Division;

• Financial Operations Division;

• Inward Listings and Institutional Reporting Division;

• Administration and Risk Management Division;

• Compliance and Enforcement Division

• Receiving of recorded exchange control

applications by allocation officers

• Allocation of recorded foreign exchange

applications to team member for

adjudication

• First level adjudication of applications by

team members

• Forwarding of adjudicated applications to

signing officers

• Second level adjudication and finalization of

applications by signing officer

• Forwarding of finalized application to

Correspondence

2. Monitor compliance with foreign exchange policy and FICA requirements

To ensure adherence to the provisions of the Exchange Control regulations by AD’s, ADLA’s and other participants.

• ADLA Supervision Division;


• Financial Operations Division;

• Inward Listings and Institutional Reporting Division;

• Plan yearly inspections

• Preparation of inspections

• Conduct inspections

• Document inspections

• Report inspections findings

• Finalise inspections

• Follow up findings

3. Implement Exchange control policy and FICA

To ensure that market participants operate within the framework of Exchange Control policy and FICA.

• Financial Operational Division;

• Inward Listings and Institutional Reporting

• Enforce compliance with the Exchange

Control Regulations (Regulations) and FICA



Division; • Analysis and

Information Flow Division;

• ADLA Supervision Division

• Participation in the Technical Committee

meeting applicable to just ADs.

• Issue Exchange Control Circulars

(“Circulars”) and update Exchange Control

Rulings

• Maintenance of policy cards

• Participation in the Rulings and Liaison

Committees (Not applicable to ADLAs)

• Recommend amendments to Exchange

Control Rulings where appropriate

4. Collection, analysis and dissemination of cross-border foreign exchange information

To provide management information on cross border foreign exchange transactions flow to stakeholders and for monitoring foreign exposure limits, exports proceeds including discretionary allowances.


• Inward Listings and Institutional Reporting Division

• Develop, maintain, evaluate and/or enhance

the Reporting Systems to ensure that they

are reliable and kept abreast with

technological advancements to satisfy user

needs

• Receipt, validation and evaluation of data to

ensure that all data is received and is in the

correct format.

• Analyze cross border foreign exchange data

and disseminate management information

on all CF transactions to provide

management information on CFE

transaction flows

• Monitor, maintain and update the inward

foreign loan database to provide



management information on inward foreign

loans

• Monitor excess discretionary allowances to

ensure compliance with prescribed limits

• Maintain and update the database of FDI’s

by corporates to provide information on

foreign direct investments by corporates

• Maintain and update the database of FDI’s

by individuals to provide information on

foreign direct investments by individuals

• Maintain and update the database of foreign

direct investments by individuals into SADC

to provide information on foreign direct

investments by individuals into SADC

• Maintain and update the database of

Emigrants Blocked Assets to provide

information on emigrants blocked assets

• Maintain a complete, accurate and reliable

database on foreign exposure by

institutional investors and inward listed

securities to ensure data on foreign

exposure by qualifying parties is readily

available

• Report information on inward listed

securities and total assets under



management by institutional investors to

provide information on inward listed

securities and total assets under

management by institutional investors to NT

and other stakeholders

• Monitor foreign exposure limits by

institutional investors to ensure compliance

with the prescribed limits.

5. Investigate alleged contraventions of the provisions of the Exchange Control Regulations and enforce FICA on ADLAs

To initiate a process for the recoupment of capital and report contraventions to law enforcement agencies.

• Compliance and Enforcement Division

• Budget for the yearly off-site investigations

and AML enforcement /investigations

• Preparation of investigation

• Perform/conduct investigations

• Document investigations

• Report investigation findings

• Follow up findings

6. Administer appointment of AD’s and ADLA’s

To ensure that only entities meeting the specified criteria are appointed.

• ADLA Supervision Division

• Adjudication of application against pre-set

criteria

• Prepare submission to Treasury for ADs

appointment

• Arrange for publication in Government

Gazette

• Inform applicant of National Treasury’s

decision

• Update list of ADs and/or ADLAs in

Exchange Control Rulings by issuing a



circular

• Advise National Treasury of new

appointments of ADLAs on a quarterly basis

• Enforce compliance with the Exchange

Control Regulations (Regulations) and FICA



2.1.5 Systems used in FNS Department

The below systems are currently implemented and being used in the FNS department:

• FinSurv Reporting System (Core System); • Apex (FinSurv Reporting System Reports); • Foreign Loans System; • Foreign Investment System; • Imports Verifications System; • Online Risk Manager; • Analyst Notebook; • Portfolio Investment System; • SharePoint; • Oracle Financial Analyser; • NDM; • E-Docs

The below sources of information are also being used by the department:

• Cards (Manual card for applications); • Forms A, E and F178; • Exports/CFE Matched Reports from Customs; • DA550/SAD500 from Customs



2.2 Functional Divisions of the Financial Surveillance Department On a functional level, the Financial Surveillance Department consists of the following functional divisions:

2.2.1 Administration & Risk Management Division The Administration & Risk Management Division is responsible for administration, handling of correspondence and risk management. The mandate of the Administration & Risk Management Division is to:

• Provide divisional support with regards to procurement, access control, SharePoint administration, records management and IT liaison;

• Manage departmental budgets; • Provide typing services and secretarial support to the department; • Manage departmental correspondence; • Ensure risk management procedures are implemented, including Business continuity plans

The Administration Section of the Administration & Risk Division is responsible for the below functions:

• Act as a liaison with IT and CSD on behalf of the department; • Manage departmental budgets; • Prepare budget variance reports; • Plan departmental staff functions; • Provide a secretarial support service to the department; • Implement Business Continuity Plans for the department; • Prepare Management Information; • Provide a correspondence control service to the department; • Manage Stationery and kitchen supplies; • Provide a record management service for the department; • Provide a typist service to the department; • Act as a SharePoint administrator for the department

The Risk Management Section of the Administration & Risk Division is responsible for the below functions:

• Responsible for the implementation of Strategic risk management and compliance; • Management of Operational risk; • Act as liaison for Specialised risks and internal audit

The Administration & Risk Management Division uses SharePoint as an administration and record management tool.



2.2.2 Compliance & Enforcement Division The Compliance & Enforcement Division is responsible for conducting investigations of alleged exchange control contraventions and enforcing the FICA on ADLAs.

Compliance & Enforcement Division Functions:

• Investigate alleged Exchange control contraventions; • Provide investigative support to the SAPS, NPA and FIC; • Act as a liaison with law enforcement agencies; • Execute the attachment and forfeiture of money and goods for benefit of the State; • Enforce the FICA on ADLAs

The below systems and distinct tools are being used by the Compliance & Enforcement Division:

• On line Risk Manager; • Analyst Notebook

The below generic systems and sources are also being used by the Compliance & Enforcement Division:

• FRS including CFE, BOP and Credit Cards; • Foreign Loan System/FDM; • Import Verification System; • Foreign Investment System/MP1423; • NDM; • Cards; • Forms A, E and F178; • Exports/CFE Matched Reports; • DA550/SAD500; • E-Docs; • SharePoint



2.2.3 Analysis & Information Flow Division The Analysis and Information flow division incorporates the collection of data in respect of all cross border foreign exchange flows and the monitoring of transactions exceeding the prescribed limits.

The function of the Analysis and Information flow division is to:

• Perform data analysis of cross border flows and prepare Management Information reports; • Oversee system development and collection of cross border transaction data; • Management and maintenance of business rules; • Monitoring of foreign loans and export and import trade transactions; • Monitoring and querying exceptions with Authorised dealers; • Perform on-going inspections of AD’s

The division is made up of 5 sections as listed below:

• Systems Development; • Information flow; • Trade Exports & Imports; • Debt Management and exception reporting; • Analysis

The below systems and tools are being used in the Analysis and Information flow division:

• FinSurv Reporting System; • Foreign Loan System; • Import Verification System; • Oracle Financial Analyser; • SharePoint; • Foreign Investment System

The below functions are performed by the sections in the Analysis and Information flow division:

Section Functions Systems used

Systems Development

• Drive new systems development; • Provide guidance and support to new AD's and

ADLA's; • Assist divisions with new product offerings in the

market; • Assist CMA countries with same source system; • Manage, maintain and update business rules.

FinSurv Reporting System; Import Verification system

Information flow • Recording daily stats of transactions received from AD's, including rejections;

• Follow up on rejections and re-submissions of transactions with AD's;

• Conduct Onsite and Offsite inspections of AD's

FinSurv Reporting System



Section Functions Systems used

Trade Exports & Imports

• Monitoring of export proceeds; • Analysis and evaluation of export data; • Verification that the import transactions have

been reported by the AD’s in compliance with the provisions the exchange control rulings.

FinSurv Reporting System

Debt Management and Exception reporting

• Capturing of manual foreign loans applications submitted to the Financial operational division;

• Provide management information on inward foreign loans transactions from Authorised Dealers;

• Manage applications formalising contraventions of limits applicable to individuals.

Analysis Collate, analyse and provide management information regarding foreign exchange and related transactions. The management information provided by the Analysis Section mainly comprises of: • Foreign investments by corporates; • Inward foreign loans; • Foreign investments by private individuals; • Cross-border flows per Balance of Payment category; • Emigrants’ remaining blocked assets.



2.2.4 ADLA Supervision Division The ADLA Supervision Division is responsible for the processing of prospective AD’s and ADLA’s applications and for conducting inspections of ADLA’s to ensure compliance with exchange control regulations and rulings.

The below functions are performed by the ADLA Supervision department:

• Approval of appointment of ADs and ADLA’s. • Due diligence and vetting process of Directors, Executive Officers and Shareholders of prospective

AD’s and ADLA’s. • Updating the ADLA’s organisational structures as per notification of changes received from ADLAs.

This also includes changes in ADLA’s shareholdings. • Updating of AD’s and ADLA’s signatories and distribution of changes to concerned parties in the

department. • Appointment of ADLA’s Compliance and Excon officers, including performing vetting processes as

per the ADLA supervision division’s requirements. • Approval of new branches of existing ADLA’s and facilitation of the registration of the new branch on

the FinSurv Reporting system. • Facilitation of the registration of new MICR codes on the FinSurv Reporting system • Perform analysis on Annual Financial Statements submitted by ADLA’s. • Perform sanction screening on institutions and their beneficiaries for approval of donation

applications received from institutions for donations to be made abroad. • Approve donation applications of institutions not listed on sanctions lists i.e OFAC, EU and World-

check lists. • Inspect Anti-Money Laundering activities as per FICA Act on a monthly basis • Inspect ADLA activities as per the Exchange Control Regulations and Rulings (Excon).

The below systems and tools are being used in the ADLA Supervision department:

• SharePoint; • Excel



2.2.5 Inward Listing & Institutional Reporting Division The Inward Listing and Institutional Reporting Division is responsible for monitoring the foreign portfolio investment allowance limits of institutional investors as well as the macro-prudential limit for Authorised Dealers.

This division also adjudicates requests from foreign entities and Authorised Dealers to inward listing foreign instruments on the JSE Limited.

• The mandate of the Inward Listing and Institutional Reporting Division includes the below: • To ensure that institutional investors are within their permissible foreign portfolio investments

allowance; • To ensure that that Authorised Dealers are within the permissible macro-prudential limit; and • To adjudicate inward listings request.

Inward Listing & Institutional Reporting Division Functions:

• Monitoring of institutional investors foreign portfolio investment allowance limits through the quarterly asset allocation reports and establish the correctness of the information submitted to us;

• Monitoring of Authorised Dealers macro-prudential limit; • Ensuring that the funds raised through the special Vostro accounts are correctly reported; and • Administering of all inward listing related applications.

The below systems and tools are being used in the Inward Listing & Institutional Reporting division:

• Portfolio Investment System; • SharePoint



2.2.6 Financial Operations Division The mandate of the Financial Operations division is to:

• Adjudicate financial applications from institutions and individuals relating to, amongst others, foreign direct investments, local and offshore borrowing, disinvestments and private individual investments etc. within the ambit of the Exchange Control Rulings and Regulations.

• Ensure compliance with terms and conditions of applications approval.

Financial Operations Division Functions:

The below functions are performed by the Financial Operations Division:

• Processing and approval of applications from Treasury Outsourced Companies and to ensure that the conditions of approval applicable to Treasury Outsourcing Companies are adhered to.

• Processing and approval of Foreign Direct Investments (FDI) applications relating to foreign acquisitions by South African corporates with regards to:

o Private equity funds offshore investments, o Establishment of holding companies in South Africa or offshore, o Establishment of international headquarter companies by non-residents in South

Africa, o Primary listing offshore by Technology, Media, Telecommunications, Exploration

and other research and development companies to ensure that the conditions of approval applicable to FDI’s are adhered to.

• Adjudicate on requests by South African residents to sell, cede or transfer South African owned Intellectual Property to non-residents.

• Analysis of annual audited Financial Statements submitted by corporates in relation to their subsidiaries offshore to ensure:

o No investments and/or loans back to the CMA, o Expansions are placed on record, o Determine the dividends declared by offshore company.

• Adjudicate on requests to transfer licence fees and royalty fees due to non-residents parties, accompanied by documentary evidence confirming the purpose and amount payable.

• Adjudicate on other miscellaneous payments falling outside the ambit of the Exchange Control Rulings.

• Authorisation of local business entities to conduct Customer Foreign Currency (CFC) accounts and/or Special CFC accounts.

• Adjudicate on requests by agents to invoice and receive foreign currency locally through their respective CFC accounts ensuring that the transactions passed are permissible as per the provisions of the Exchange Control Rulings.

• Monitoring AD’s to ensure that they comply with the provisions of the exchange control rulings when granting local financial assistance to affected companies.

• Processing of JSE related applications such as new products on JSE, derivatives, listing of warrants, circular to shareholders, delisting of a company listed on the JSE, endorsement of non-resident share certificates, listing of a bank and/or bank holding company, the issue of bearer securities, restructures, mergers and changes in control where non-residents are involved, the declaration of a dividend in specie or special dividend for any purpose, the



listing of a quoted South African company on a foreign stock exchange, dual listings and primary listing offshore.

• Processing of capital transfers applications relating to emigrants and South African residents which are above the specified limit to ensure that such applications are accompanied by a Tax Clearance Certificate issued by South African Revenue Service.

• Analysis of annual portfolio status reports to determine the exact amount transferred abroad, to ensure that stipulated terms and conditions are adhered to, ensure that there are no breaches and ensure that the investment vehicles are permissible i.e. no trusts.

• Process requests by South African residents to participate in offshore Share Incentive Schemes where the value of the shares is in excess of the specified limit.

• Adjudicate on applications relating to income and inheritance transfers to non-residents and emigrants.

• Monitoring of AD’s to ensure that Foreign and Trade Finance Loans authorised by the AD are in accordance with the provisions of the exchange control rulings.

• Ensuring that bonds issued offshore comply with the set terms and conditions of approval. • Process applications relating to guarantees falling outside the ambit of the Exchange Control

Rulings. • Grant Imports Letter of Undertaking dispensation to qualifying companies from the

requirement to submit supporting documentation to their Authorised Dealers for every foreign exchange transaction related to an import transaction.

• Process off-market transactions with discounts. • Processing of hedging applications to ensure that contracts were established against firm

and ascertainable foreign commitments. • Adjudicate on Single discretionary allowance requests in excess of R1m. • Referral of high impact transactions to National Treasury. • In addition to the above, various applications relating to matters outside the parameters of

the Exchange control Rulings are received and processed by the Financial Operations Division.

The below systems and tools are being used in the Financial Operations department:

• SharePoint; • NDM; • FRS; • FLS; • ORM; • SharePoint (Various Excel spreadsheets); • IVS



3 Application Architecture Definition The purpose of this section is to provide a high-level overview of the FNSD Application Eco-System for information purposes. Service Provider must perform a detailed analysis of the current environment (business, application and technology) during implementation and derive its own conclusions about the desired target architecture and roadmap associated with it.

3.1 FNSD Application Eco-System

3.1.1 Baseline Application Eco-System

FNSD rely on a myriad of bespoke and common-of-the-shelf (COTS) applications to collect and manage the data and information that drives its daily operations. These are depicted below:

Figure 3: FNSD Baseline Application Eco-System Overview

Table 8: FNSD Baseline Application Eco-System Described

System Type Purpose TECHNOLOGY Foreign Investment System

Peripheral Application BESPOKE

The purpose of the system is to record applications received for foreign investments by Entities resident in the country, and to monitor the exposure thereof, and to query the data and to report thereon.

FIS ORACLE, JAVA

Foreign Loan System

Peripheral Application

The purpose of the system is to record applications received for foreign loans by Entities resident in the country, and

FLS ORACLE, JAVA



System Type Purpose TECHNOLOGY BESPOKE to monitor the drawdowns, repayments

and interests on the loan, and to query the data and to report thereon. It was developed in order to have a reliable source of information of South Africa's debt profile. The objective of the system is to ensure accurate and comprehensive reporting of loan related data by AD for compilation of foreign debt statistics and repayment profile to support monetary policy decisions

Analyst Notebook System

Peripheral Application COTS

The purpose of the system is to provide a consolidated view of an Entity under investigation and to sketch a profile for it.

IBM: i2 Analyst’s Notebook

Correspondence Registration System


The purpose of the system is to record the receipt of applications and correspondence from Entities external to the Bank to acknowledge receipt thereof.

CRS MAINFRAME - COBOL

Financial Analyser System


The purpose of the system is to create consolidated views of the data extracted from FRS.

OFA ORACLE: FINANCIAL ANALYSER

Code Table System


The purpose of the system is to record and maintain codes (master data); and it serving as reference data when validating the integrity of the data received from RE; and a lookup list to pass parameters to a query.

ORACLE, JAVA

Portfolio Investment Reporting System


The purpose of the system is to record a report of returns on assets under management and to monitor the exposure of these offshore portfolio investments done by institutional investors, and to query the data and to report thereon.

PIRS ORACLE, JAVA

Financial Surveillance Reporting System

Core Application BESPOKE

FRS is at the core of the Eco-System. The purpose of the system is to process cross border foreign exchange transactional data received from RE (Authorised Dealers, Card Reporting Entities, and Direct Reporting Entities). The transactional data is used by the peripheral systems in the Eco-System to satisfy its reporting needs.

FRS ORACLE, JAVA

Online Risk Manager System


The purpose of the system is to record data related to informants and investigations, to search and analyse and to present graphical management information, to reveal and identify modus operandi, networks, links and trends, and to compile profiles and to manage investigation cases.

ORM ONLINE INTELLIGENCE: RISK MANAGER

Import Verification Application The purpose of the system is to IVS



System Type Purpose TECHNOLOGY System BESPOKE process import transactional data

received from the SARS’s Customs Division.

ORACLE, JAVA

Electronic Document Management System

Enterprise-Wide Application COTS

The purpose of the system is to record electronic documents and related meta data.

e-DOCS MICROSOFT: SHAREPOINT

Advance Queue System

Interface COTS

The purpose of the interface-system is to collect and load data from FRS into queues destined for other database schemas and to unload the queues to the applicable database schema (FRS Data Mart, FRS Interim, IVS, FLS, FIS) at the scheduled times.

ORACLE: ADVANCE QUEUE MANAGER

Application Programming Interface

Interface COTS

The purpose of the interface-system is to collect and load data from FRS into multidimensional cubes on another database schema in OFA.

ORACLE: FINANCIAL ANALYSER

Electronic Data Interchange System

Interface COTS

The purpose of the interface-system is to receive data securely and reliably over the internet from SARS.

AS2 EDI AS2

Database Link (CT & RM)

Interface COTS

The purpose of the CT interface-system is to directly access the code table data (master data) from different peripheral database schemas or the application server, whilst the RM interface-system is used by ORM to directly access transactional data from FRS, FIS and FLS.

ORACLE

Web Services Interface

Interface COTS

The purpose of the interface-system is to enable the search for and linking of documents from e-Docs to business objects in ORM.

MICROSOFT: SHAREPOINT WEBSERVICES

Data Exchange System

Interface BESPOKE

The purpose of the interface-system is to transport submission files from RE securely over the internet or SWIFTNet, validates the file format and schema layout, takes care of hashing and encryption and provides a log file of when the file was submitted, a reply received thereto as well as any errors in the file.

SARBDEX

Bridge Interface Interface COTS

The purpose of the interface-system is for Analyst Notebook System to access data, and executes queries, from ORM and to return it to the interface.

iBridge



Figure 4: Baseline Application Eco-System Interaction Diagram

3.1.2 Target Application Eco-System

BSTD is envisioning a simplified IT infrastructure to help improve the efficiency, maintenance and support of applications, to enhance data quality and to upgrade to next-generation applications by consolidating and decommissioning current applications. This vision and desired target state is depicted below. Service Provider may propose alternate target application architecture after detail analysis of the business processes and current applications.



Figure 5: FNSD Target Application Eco-System Overview

Table 9: FNSD Target Application Eco-System Described

System Type Purpose TECHNOLOGY Data Quality Assurance System


The purpose of the system is to verify and ensure the quality and integrity of data.

EA Standards Based

Master Data Management System


The purpose of the system is to manage and share business critical information (common master data) across the Bank.

EA Standards Based

Knowledge Computing System

Core and Enterprise-Wide Application COTS Preferred

The purpose of the system is to process and prepare transactional data received from RE’s and SARS, to virtually integrate data from several structured, semi-structured and unstructured data sources, to enable the exploration of the data from a single workbench, and to enable manual or automatic advance analytics of the data to attain insight and decisions.

Could be new EA standard Big Data Supporting Platform

Forms Administration System

Peripheral Application COTS Preferred

The purpose of the system is to enable the recording and workflow, interactively or electronically, of various types of input forms across the industry (internal and external stakeholders). Forms mean e.g. ADLA Application Form, AD Urgent Applications, Foreign Loan Approval Requests, Foreign Investment Form, Quarterly Asset Allocation Reports, Foreign Loan Draw Down Requests, Foreign Loan Payment Request.

EA Standards Based



System Type Purpose TECHNOLOGY Online Risk Manager System (retain from baseline)


The purpose of the system is to record data related to informants and investigations, to search and analyse and to present graphical management information, to reveal and identify modus operandi, networks, links and trends, and to compile profiles and to manage investigation cases.

ORM ONLINE INTELLIGENCE: RISK MANAGER

Analyst Notebook System (retain from baseline)


The purpose of the system is to provide a consolidated view of an Entity under investigation and to sketch a profile for it.

IBM: i2 Analyst’s Notebook

Electronic Document Management System (retain from baseline)


The purpose of the system is to record electronic documents and related meta data.

e-DOCS MICROSOFT: SHAREPOINT

Enterprise Integration (currently being deployed)

Enterprise-Wide Interface

The purpose of the interface-system is to provide an enterprise-wide integration platform (event-driven, message-orientated) for source and target systems internal and external to the Bank, in a secure and reliable manner.

IBM: WEBSPHERE MQ

Virtual Integrator Enterprise-Wide Interface

The purpose of the interface-system is to provide unified access to disparate structured, semi-structured and unstructured data sources.

Could be new EA standard Big Data Supporting Platform

Important Notes:

• The assumption has been made that the Forms Administration System will accommodate the features required by the FLS. Ideally the information should be integrated from the back office systems of the originator.

• The Analyst Notebook System should ideally be replaced by functionality provided by the Knowledge Computing System.

• Service Provider to make a recommendation after the detailed analysis of the environments was conducted.

• The following summarized the replacement strategy:

Table 10: Architecture Replacement Strategy

Baseline Application Target Application

Financial Surveillance Reporting System (FRS) Knowledge Computing System

Foreign Investment System (FIS) Forms Administration System

Foreign Loan System (FLS) Forms Administration System

Correspondence Registration System (CRS) Forms Administration System

Financial Analyser System (OFA) Knowledge Computing System

Code Table System Master Data Management System

Portfolio Investment Reporting System (PIRS) Forms Administration System

Import Verification System (IVS) Forms Administration System



Figure 6: Target Application Eco-System Interaction Diagram

3.2 FNSD Application Eco-System Architecture Transition Roadmap BSTD prefers a phased approach to transition the baseline application architecture to the target application architecture, and wants to do so in three phases. The change in the application architecture landscape for each transition informs the scope of project for that phase of the programme (included, but not limited to). Service Provider may propose an alternate application architecture transition roadmap after detail analysis of the business processes and current applications. This is currently envisaged as described below.



3.2.1 TRANSITION 1

Figure 8: Transition 1 TARGET

State Type Name Baseline Application Architecture Application Transition Architecture 1 added Application Data Quality Assurance System

added

added Application Knowledge Computing System

added added Application Master Data Management System

added

added

Used Interfaces (Analyst Notebook System -> Virtual Integrator)

added added

Used Interfaces (Correspondence Registration System -> Virtual Integrator)

added

added

Used Interfaces (Data Quality Assurance System -> Enterprise Integration)

added added

Used Interfaces (Electronic Document Management System -> Enterprise Integration)

added

added

Used Interfaces (Electronic Document Management System -> Virtual Integrator)

added

Figure 7: Transition 1 BASE



State Type Name Baseline Application Architecture Application Transition Architecture 1 added

Used Interfaces (Foreign Investment System -> Enterprise Integration)

added

added

Used Interfaces (Foreign Investment System -> Virtual Integrator)

added added

Used Interfaces (Foreign Loan System -> Enterprise Integration)

added

added

Used Interfaces (Foreign Loan System -> Virtual Integrator)

added added

Used Interfaces (Knowledge Computing System -> Enterprise Integration)

added

added

Used Interfaces (Knowledge Computing System -> Virtual Integrator)

added added

Used Interfaces (Master Data Management System -> Enterprise Integration)

added

added

Used Interfaces (Master Data Management System -> Virtual Integrator)

added added

Used Interfaces (Online Risk Manager System -> Enterprise Integration)

added

added

Used Interfaces (Online Risk Manager System -> Virtual Integrator)

added added

Used Interfaces (Portfolio Investment Reporting System -> Enterprise Integration)

added

added

Used Interfaces (Portfolio Investment Reporting System -> Virtual Integrator)

added added Interface Enterprise Integration

added

added Interface Virtual Integrator

added removed Application Code Table System removed

removed Application Financial Analyser System removed removed Application Financial Surveillance Reporting System removed removed Application Import Verification System removed removed

Provided Interfaces (Code Table System -> Database Link (CT)) removed

removed

Provided Interfaces (Financial Analyser System -> Application Programming Interface) removed removed

Provided Interfaces (Financial Surveillance Reporting System -> Advance Queue System) removed

removed

Provided Interfaces (Knowledge Computing System -> WebService Interface) removed removed

Used Interfaces (Financial Surveillance Reporting System -> Application Programming Interface) removed

removed

Used Interfaces (Financial Surveillance Reporting System -> Data Exchange System) removed removed

Used Interfaces (Financial Surveillance Reporting System -> Database Link (CT)) removed

removed

Used Interfaces (Financial Surveillance Reporting System -> Database Link (RM)) removed removed

Used Interfaces (Foreign Investment System -> Advance Queue System) removed

removed

Used Interfaces (Foreign Investment System -> Application Programming Interface) removed removed

Used Interfaces (Foreign Investment System -> Database Link (RM)) removed

removed

Used Interfaces (Foreign Loan System -> Advance Queue System) removed removed

Used Interfaces (Foreign Loan System -> Application Programming Interface) removed

removed

Used Interfaces (Foreign Loan System -> Database Link (CT)) removed removed

Used Interfaces (Foreign Loan System -> Database Link (RM)) removed

removed

Used Interfaces (Import Verification System -> Advance Queue System) removed removed

Used Interfaces (Import Verification System -> Application Programming Interface) removed

removed

Used Interfaces (Import Verification System -> Electronic Data Interchange System) removed removed

Used Interfaces (Online Risk Manager System -> Database Link (RM)) removed

removed

Used Interfaces (Portfolio Investment Reporting System -> Database Link (CT)) removed removed Interface Advance Queue System removed removed Interface Application Programming Interface removed removed Interface Database Link (CT) removed removed Interface Database Link (RM) removed removed Interface Electronic Data Interchange System removed



3.2.2 TRANSITION 2


State Type Name Application Transition Architecture 1 Application Transition Architecture 2 added Application Forms Administration System

added

added

Used Interfaces (Forms Administration System -> Enterprise Integration)

added added

Used Interfaces (Forms Administration System -> Virtual Integrator)

added

removed Application Correspondence Registration System removed removed Application Foreign Investment System removed removed Application Portfolio Investment Reporting System removed removed

Used Interfaces (Correspondence Registration System -> Virtual Integrator) removed

removed

Used Interfaces (Foreign Investment System -> Enterprise Integration) removed




State Type Name Application Transition Architecture 1 Application Transition Architecture 2 removed

Used Interfaces (Foreign Investment System -> Virtual Integrator) removed

removed

Used Interfaces (Portfolio Investment Reporting System -> Data Exchange System) removed removed

Used Interfaces (Portfolio Investment Reporting System -> Enterprise Integration) removed

removed

Used Interfaces (Portfolio Investment Reporting System -> Virtual Integrator) removed removed Interface Data Exchange System removed

3.2.3 TRANSITION 3


State Type Name Application Transition Architecture 2 Application Transition Architecture 3 removed Application Foreign Loan System removed

removed

Used Interfaces (Analyst Notebook System -> Bridge Interface) removed




State Type Name Application Transition Architecture 2 Application Transition Architecture 3 removed

Used Interfaces (Electronic Document Management System -> WebService Interface) removed

removed

Used Interfaces (Foreign Loan System -> Enterprise Integration) removed removed

Used Interfaces (Foreign Loan System -> Virtual Integrator) removed

removed

Used Interfaces (Online Risk Manager System -> Bridge Interface) removed removed

Used Interfaces (Online Risk Manager System -> WebService Interface) removed

removed Interface Bridge Interface removed removed Interface WebService Interface removed



3.3 Extended Baseline Application Architecture Definition This section provides some more detailed information about some of the baseline applications.

3.3.1 Financial Surveillance Reporting System (FRS)

Also referred to as ‘REPORTING SYSTEM’ or ‘FinSurv Reporting System’ means the electronic system used to transmit data to the Bank in agreed format. Used by FNSD and Research Department. The purpose of the FRS is to provide relevant, accurate and timeous information (data on cross-border foreign exchange transactions) in the context of the move towards the total abolition of controls on cross-border transactions and payment flows. To ensure accurate and comprehensive reporting of data on cross-border foreign exchange transactions for:

• Compilation of balance of payments statistics by the SARB’s Research Department. • Compilation of foreign debt statistics and repayment profiles to support monetary policy decisions. • Compilation of statistical information which will indicate to management the nature, volume and

values of the various cross-border flows and provide them with the appropriate information for economic and financial management decisions as well as planning and policy formulation.

• Monitoring of export proceeds and import payments. • Provision of data to the SARS and the FIC.

Cross border foreign exchange transactional data is most important for national and international policy formulation. External aspects, such as payment imbalances and inward and outward foreign investment play a leading role in economic and other policy decisions in the increasingly interdependent world economy. Such data is also used for analytical studies, that is, to determine the causes of payment imbalances and the need to implement adjustment measures; relationship between merchandise trade and direct investment; aspects of international trade services; international banking flows and stocks; asset securitisation and principal market developments; external debt problems, income payments and growth; and links between exchange rates and current and financial account flows. In addition, external data is utilised extensively, along with other variables, for balance of payments projections and their interrelationship with changes in countries’ stocks of external assets and liabilities. Furthermore, balance of payments and international investment position data constitute an indispensable link in the compilation of data for various components of the national accounts (e.g. production accounts, income accounts, capital and financial accounts, and the related measurement of national wealth).

Cross border foreign exchange transactional data is reported on a daily basis to the Bank by the Reporting Entities (RE). Such daily information is received via the SARBDEX platform. The IVS, the FLS, the FIS and the PIRS are dependent on the data received via the FRS.

From the application menu, the following functionality is extended:

Notes:

• • BOPCUS2 Data between 2004-10-01 to 2013-08-18 • BOPCARD1 Data between 2005-04-01 to 2013-08-18 • BOPCUS1 Data between 2001-04-01 to 2004-09-30

Reports Menu (Data after 2013-08-18) BOPCUS2 and BOPCARD1 Menu BOPCUS1 Menu



Reports Menu (Data after 2013-08-18) BOPCUS2 and BOPCARD1 Menu BOPCUS1 Menu

• Account Identifier Search • Account Identifier • Branch Code Search • Cannot Categorise Search • Card Indicator Search • Card Merchant Code Search • Card Merchant Name Search • Category Search • Currency Search • Core Transactions Search • Core Transactions (excluding

import and export data) Search • Electronic Commerce Indicator

Search • File Reference Search

(transactions associated with xml file)

• FinSurv total per process date – stored procedure

• Finsurv total per value date • Full transactions detail • High value transactions (+50m)

per value date • Hub code search • Location country search • Midrate report • Money transfer agent search • Non resident country search • Non resident party search • Pos entry mode search • Process date search • Provinice search • Resident identification search • Resident party search • Strate reference search • Subject search • Transaction search • Validate identity number

(construct of id)

• Account Identifier • Branch Code Search • Cannot Categorise Search • Card Indicator Search • Card Merchant Code Search • Card Merchant Name Search • Category Search • Customs Client Number Search • File Reference Search

(transactions associated with xml file)

• Full transactions detail • High value transactions per

value date • Location country search • Money transfer agent search • Non resident country search • Non resident party search • Process date search • Resident identification search • Resident party search • Subject search • Transaction search • Card Resident Totals • ADLA Totals

• Full transaction details

Information Flow Menu Customs Menu Research Menu

• Audit Core Report • Audit Rand Value Exceptions • Audit Cancellations not

Replaced • Audit Delayed Reporting • Audit Future Dated Reporting • Stats Active Error Details • Stats All Error Details • Stats Error Variances • Stats Total Variances • Stats Cancellations with no

Original Transactions • Stats Duplicate File Reference -

Transactions not with same status on record

• Stats Duplicate File Reference - Transaction not on record

• Resident Transactions Details Report (CCN)

• Resident Transactions Details Report (Name)

• Branch Transaction Details • Custom Client Number and AD's

Report (CCNA) • Macro Matching of Exports

• Research Transaction Details • Research Core Transactions • Resident Party Search • Research Transaction Details -

BOPCUS2 (2004-10-01 to 2013-08-18) & BOPCARD1 (2005-04-01 to 2013-08-18)

• Resident Party Search - BOPCUS2 (2004-10-01 to 2013-08-18) & BOPCARD1 (2005-04-01 to 2013-08-18)



Information Flow Menu Customs Menu Research Menu

• Reporting Entity Market Share • Audit Enrichment Data

Analysis Menu Monitor Menu Administration Menu

• Finsurv Totals per Value Date • Finsurv Totals per Value Date

Country • Finsurv Totals per Process Date • Finsurv Totals per Process Date

Country • Finsurv Totals per Month & Year • High Value Transactions (+50

Million) per Value Date • High Value Transactions (+50

Million) per Process Date • Money Transfer Agent Totals • Money Transfer Agent

Totals_Country • Card Resident Totals • Card Resident Totals_Country • Card Non Resident Totals • Card Non Resident

Totals_Country • Industrial and Sector Analysis • Industrial and Sector Analysis

Country • ADLA Totals • Loan Comparison

• Queue Monitor (count number of incoming transactions per 30 min – in log)

• Batch Monitor (monitor whether batch was processes successfully)

• Create Roles • Create Users

3.3.2 Import Verification System (IVS)

IVS means the Import Verification System to enable Authorised Dealers to authenticate SARS Customs import declaration forms presented by their customers.

Customs submits data to the SARB on a daily basis in respect of all import transactions and Customs Client Numbers, which are stored in a database linked to the IVS. Vouchers of Corrections finalised by Customs will update the database accordingly. Data submitted to and from the IVS is via an inter-active web service or a web site. Minimum data is required to update the IVS to authenticate the Customs Notification presented by the importer to the Reporting Entity. Due to the use of an inter-active web service, various structures is available. The structures cater for the following type of transactions:

1. The submission of data to the SARB and to authenticate the Customs Notification (CN1) issued by Customs;

2. Transactions submitted to the IVS can be cancelled from the IVS subject to certain conditions;

3. The receipt of a response from the SARB with additional data when applicable or a rejection message in cases where data cannot be accepted by the SARB;

4. An enquiry function is available to Customs and the Reporting Entities to extract data from the IVS database.

5. The response from the IVS database in respect of enquiries.



Reference to FinSurv message means the transaction reported to the SARB via the FinSurv Reporting System.

Cancellation of transactions: Transactions previously reported via the FinSurv Reporting System is automatically cancelled from the IVS database if the transaction is cancelled from the FinSurv database.

Reversal of a transaction: Transactions reversed by the Reporting Entity using category 100 via the FinSurv message, automatically updates the IVS database. The transaction reference number of the original transaction supplied in the ReversalTrnRefNumber and ReversalSequence attributes in the FinSurv message activates the process.

Statistical information available to Reporting Entities and the SARB: Advance payments effected by a Reporting Entity are flagged in the IVS database via the FinSurv database to indicate future receipts of data from Customs. Once the Customs Declaration and Notification have been received by the Reporting Entity, the data is submitted to the IVS to finalise the transaction and to link the specific Customs document with the FinSurv transaction.

Reporting Entities have access to the IVS database for statistical purposes and to use the system as a reminder system to follow up on non-delivery of goods imported or outstanding Customs Notifications and Declarations.

During the authentication process and on an ad-hoc basis, Reporting Entities have access to historic payments effected against a specific Customs Notification and will receive the value date(s), Rand amount(s) , Foreign value(s) and foreign currency code(s) from the SARB via the web service or web site.

The SARB is able to identify the following:

1. All advance payments not confirmed by a Movement Reference Number (MRN) per Reporting Entity. The Reporting Entity has to follow these transactions up with the importer. Reporting Entities should be able to automate e-mail messages to importers to obtain the outstanding Customs Notifications provided the e-mail details forms part of the FinSurv transaction.

2. All imports with a MRN, which are not linked to a payment, could be due to incorrect categorisation, credit terms etc. The SARB follows these transactions up.

3. Actual import payments which exceed the value declared to Customs is followed up directly by Customs.

Structure of the SCHEMA of the Import Verification System (IVS) in respect of data submitted by Reporting Entities to the SARB. The structure reflected is based on XML. Reporting Entities have the option to use either a web service or a web site to communicate with the SARB and to receive a response from the SARB. Includes the following messages: ImportVerification, VerificationResponse, StatsEnquiry, StatsResponse

As part of normal communication back to the Reporting Entity in respect of each message submitted to the IVS at the SARB, the SARB advises the error(s) per transaction. In respect of transactions successfully updated in the IVS, a confirmation reference number and IVS reference number applicable to each transaction will be advised. In cases where the transaction was not submitted successfully, only an IVS reference number will be created by the IVS database for tracking purposes. In the case of an authentication



via the FinSurv Reporting System, no IVS reference number will be advised. The confirmation of the successful transaction via the FinSurv Reporting System replaces the IVS reference.

Message to obtain statistical data from the Import Verification System: Reporting Entities have access to the IVS database to extract data for their own purposes. Only data applicable to the Reporting Entity requesting the data is available. Reporting Entities does not have access to view data submitted by another Reporting Entity except to view dates, and amounts affected against a specific Customs Notification. If a transaction reference number is included in the report, it will be applicable to the requesting Reporting Entity. The StatsEnquiry Element will be available for these requests. The following information will be available to Reporting Entities:

1) To enquire if payments were effected previously against a specific MRN.

2) To view all import payments per Customs Client Number.

3) To view all import payments per Customer.

4) To view all outstanding Customs Declarations and Notifications where advance payments were affected by the requesting Reporting Entity.

5) To view all import transactions per category.

6) To view total amounts per period per customer / Customs Client Number / Description.

Response back to Reporting Entities after an Enquiry has been submitted to the IVS. The response is reflected under the StatsResponse Element of the message.

As part of normal communication back to the Reporting Entity in respect of each enquiry message submitted to the SARB, the SARB advises the error(s) per transaction.

In respect of transactions responded to from the IVS database, an IVS reference number applicable to each transaction is advised.

In addition, historic data applicable to each transaction related to a specific Customs Declaration and Notification (CD1 and CN1) is supplied to the Reporting Entity reflecting the value date(s), Rand amount(s), foreign amount(s) and foreign currency code(s).

Enquiry Options Menu Verification Options Menu User Menu

• Movement Reference Number (MRN)

• Customer Client Number (CCN Transaction)

• Customer Client Number (CCN Enquiry)

• Customer Name • BOP Category Totals • All Outstanding Documents • Totals for the Authorised Dealer • Transport Document Number • All Description • BOP Transaction Reference

Number • LRN • IVS Reference Number

• No MRN • Non-Resident Rand Account • Advance Payment

• Register User • Maintain User • Create Admin User



Enquiry Options Menu Verification Options Menu User Menu

• MRN Confirmation Reference Number

3.3.3 Portfolio Investment Reporting System (PIRS)

The main purpose of the system is to provide a tool to monitor portfolio investments done by institutional investors. Institutional investors on a quarterly basis provide reports on assets under management, per fund managed, via the internet or via electronic files, to the Portfolio system. Data received uploads to the Portfolio database through an automated process. In addition, the Portfolio section also captures reports on assets under management, manually received on hard copies.

Prudential returns - Macro-prudential foreign exposure limit return: Authorised Dealers must complete and submit a macro-prudential foreign exposure limit return on a monthly basis to the Financial Surveillance Department by the 20th working day of the following month.

Portfolio investments: Institutional investors must submit a quarterly report to the Bank providing information on the allocation of assets according to the major asset classes. Where relevant they must also submit information from institutions in excess of the foreign asset limit on proposed portfolio adjustments to bring foreign asset levels back in line. Managing institutions must also include a list of their institutional clients. Quarterly Asset Allocation reports for:

• Collective investment scheme management companies • Investment managers • Long-term insurers investment linked business policies • Long-term insurers non-linked policies • Retirement funds

Asset Class Deviations: If there are by comparison asset class deviations of 30% in the grand total of the Rand denominated domestic assets, 30% in the grand total of the Rand denominated foreign assets or 30% in the grand total of foreign denominated assets, in respect of the preceding quarterly asset allocation report, the current report will not be accepted. This deviation is only applicable to institutional investors with total assets under management in excess of R1 MILLION.

First-time reports: Institutions must first advise the Exchange Control Department of the name of the Fund to be loaded on to the database where after first-time reports may be submitted electronically via the Web-interface and/or Electronic Bulk Reporting System. Alternatively, first-time reports may be submitted to [email protected] for manual capturing.

Over Exposures: In the case of over-exposure i.e. the limit of 20% or 30% (Portfolio investment allowance) and/or 5 % (African allowance) is exceeded; the quarterly asset allocation report will be accepted for the first time. However, the Institution will be notified electronically to submit the corrective measures via [email protected] and/or an Authorised Dealer. The following limits are applicable per industry type:

• Retirement Funds (20%) • Long-term Insurers Non Linked Policies (20%)


mailto:[email protected]



• Long-term Insurers Investment Linked Business (30%) • Investment Managers (30%) • Collective Investment Scheme Management Companies (30%)

Web-interface (Single funds): The web-interface for electronic submission of the quarterly asset allocation reports refers to the web-page that enable Institutions to submit reports (single funds) by means of the internet. The Institutions are able to create usernames and passwords thereby gaining access to the web-interface, defining their profiles and subsequently submitting the asset allocation reports electronically.

Electronic Bulk Reporting System: The Electronic Bulk Reporting System is a platform that enables Institutions to submit their reports in a bulk format using XML files via SARBDEX. The Institutions are therefore able to write XML files and submit same via SARBDEX. The Business Systems and Technology Department (BSTD) therefore receive the XML files via SARBDEX and upload same on to the Portfolio Investments System.

[email protected]: Refers to a dedicated email address to process queries and any other correspondence from the fund administrators.

3.3.3.1 PIRS Application for external use

PIRS Log-in screen: For external users, PIRS uses a secure socket layer with full encryption to grant users access to the application.

Capture: The capture option is selected when you want to submit a report. The report types are Retirement Funds, Investment Managers, Collective Investment Scheme Management Companies, Long Term Insurers Non Linked Policies and Long Term Insurers Investment Linked Business.

• Capturing Reports - to capture header detail for an asset allocation report • Capturing all the Meta Data • Capturing Asset Allocations

Error Messages and What they mean: When the submit button is clicked, the system does a variety of checks to ensure the integrity of the data. These checks follow a certain order and there are actions that can be performed to fix the errors. The errors and actions are discussed below.

• Duplicate Error: A duplicate error occurs when a report of the same fund and quarter has already been captured and accepted in the database.

• Pending report: Should a report reflect an over-exposure or a deviation, it will be considered as pending until such time that Finsurv officials have approved or rejected the reasons provided for the anomalies. No follow-up reports can be captured until the pending report is finalized.

• No prior report error No prior report occurs when the report for the quarter preceding the one that is being captured is not in the system. This happens mainly when the reporting institution has not reported before. To fix this error, submit the previous quarter or if it is a first time report then send the report to SARB. Only SARB can capture first time reports. Prior reports are used in calculating significant deviations. The only time that a report is accepted without a prior one is when the report submitted is deemed a first time report.

• Over exposure error. This happens when the total foreign exposure for a fund exceeds the prescribed limit. The limits are set by the Minister of Finance and periodically reviewed. To view the current limits see the “Over Exposure Limits” in the Help menu. The over exposure calculation is the




sum of the rand denominated foreign assets and the foreign currency denominated foreign assets divided by the sum of total assets (domestic assets + rand denominated foreign assets + foreign currency denominated assets). An over exposed report is not written to the database unless reasons for it is supplied. The report is only accepted on the database when a Finsurv official has accepted the explanation. To fix this error, reasons must be captured in the provided field explaining the over exposure and giving corrective measures. Optionally a file providing the reasons can be attached.

• Deviation error. This happens when the totals per column of the current report varies from the totals per column of the previous quarter report by a prescribed limit. A report with a deviation will not be written to the database unless a reason for the deviation is captured. The report is only accepted on the database when a Finsurv official has accepted the explanation. To fix this error, reasons must be captured in the provided field explaining the reason for the deviation. Optionally a file providing the reasons can be attached.

Received Report A report will be submitted by the system when it has no errors or contains an over exposure or significant deviation with reasons provided.

Reports: The reports option of the menu is used to view all the captured asset allocation reports. The respective fund types are reflected in the menu list. Each selection shows only the captured reports for the particular fund type.

3.3.3.2 PIRS Application for internal use

PIRS Reports Menu Internal Admin Menu Capture Menu

• Institutional : African Assets • Institutional : Foreign Assets • Retail : African Assets • Retail : Foreign Assets • Treasury Report - Direct

Download • Totals per Fund Report • Quarterly Statistical Report • Daily Statistical Report • Top 100 Report • Active Funds Report

• Periods • Funds • Fund Administrators • Fund Type • Limit Updates • External Users • Access Control • Audit Report • Fix Fund Codes in data • Fix Fund Names in data • Fix Admin Codes in data • Retirement Fund Fix Report • Investment Managers Fix Report • Collective Investment Scheme

Management Companies Fix Report

• Long Term Insurers Non-Linked Policies Fix Report

• Long Term Insurers Investment Linked Business Fix Report

• Retirement Funds • Investment Managers • Collective Investment Scheme

Management Companies • Long Term Insurers Non-Linked

Policies • Long Term Insurers Investment

Linked Business

Return Menu (view submitted reports)

• Retirement Funds • Investment Managers • Collective Investment Scheme Management Companies • Long Term Insurers Non-Linked Policies • Long Term Insurers Investment Linked Business



3.3.4 Foreign Investment System (FIS)

Authorised Dealers (ADs) may allow the transfer, as a foreign capital allowance, of up to R2 million per private individual who is a taxpayer in good standing and over the age of 18 years, for investment purposes abroad. Prior to authorising the transaction, ADs must ensure that a Form MP1423 (Form) is completed in duplicate, signed by the applicant and that a duly completed “Tax Clearance Certificate (in respect of foreign investment)” for the applicant was issued by the South African Revenue Services (SARS). The original Form must be submitted to FNSD. The ADs are compelled to retain the copy of the Form and the duly completed “Tax Clearance Certificate (in respect of foreign investment)” for a period of five years for inspection by FNSD.

The business process to capture a new Form consists of four parts. In part one FNSD receives the Forms from the ADs; in part two FNSD verifies whether or not the Forms were reported on CBFET; in part three FNSD captures the Forms on the FIS and validates the Forms’ data and in part four FNSD sends the original Form or a copy thereof back to the AD if an error occurred.

Part one: FNSD receives Forms from ADs in three different ways:

• Hard copies - ADs forward hardcopies to FNSD. • Flat File - Investec and Nedcor submit Forms via secured e-mail. • CBFET - Momentum and Sanlam submit Forms via CBFET.

Part two: FNSD checks whether or not the AD reported the submitted Forms on CBFET as it is imperative that all Forms are reported. Information on the submitted Form and on CBFET should correspond.

Part three: FNSD captures and validates the Forms on the FIS. All Forms are captured whether reported or not on CBFET. The following are the steps to capture and validate a Form:

• FNSD awards a unique reference number (sequence number) to each Form. • FNSD group the Forms into batches of approximately 20 Forms. • FNSD numbers each batch for archiving purposes. • Before capturing a new batch, a table for the batch is created. • FNSD enters the Forms’ data of each batch into the FIS. • After FNSD captured all the Forms of a batch, an option is selected to update the FIS’s databases.

The FIS then validates the entered ID/TAX number for each Form. • If the Form’s data is correct, the system saves the data to the “Information” table in the “FISDATA”

database of the FIS and removes the Form’s data from the batch’s table in the ”FIS” database of the FIS.

• After the system validated the batch’s Forms, the FIS clears the “FaultInfo” table in the “FISDATA” database and copies the data, of all the Forms that failed the validation, from the batches’ tables in the “FIS” database to the “FaultInfo” table in the “FISDATA” database. If the validation of the Form’s data failed, the system does not remove the Form’s data from the batch’s table in the “FIS” database.

Part four: FNSD referrers the Form back to the AD. If an AD did not report a Form correctly on CBFET, FNSD sends a copy of the Form back to the AD to report it. If a validation error occurred during the capture process FNSD sends the original Form back the AD for correction.

There are two reasons why ADs can resubmit a Form.

• The original submission not reported on CBFET. • A validation error occurred in the original submission.

The process for capturing a resubmitted Form consists of four parts:



Part one, FNSD receives the resubmitted Forms together with the correction notices from the ADs. In part two FNSD verifies whether or not the Forms were reported on CBFET; in part three FNSD captures the Forms on the FIS, validates the Forms’ data and in part four FNSD sends the original Form or a copy thereof back to the AD if an error occurred.

Part one: FNSD receives the resubmitted Form together with a notice of correction from the AD. All resubmitted Forms are send as hard copies to FNSD except the Forms received from Investec and Nedcor who send the resubmitted Forms as well as the notices of correction via secured e-mail.

Part two: FNSD checks whether or not the AD has reported the resubmitted Forms on CBFET as it is imperative that all resubmitted Forms are reported. The information on the Form and on CBFET should correspond. If FNSD receive a resubmitted Form formerly not reported on CBFET, reporting it now, the process ends successfully.

Part three: FNSD captures and validates the resubmitted Forms on the FIS. The steps followed to capture and validate a resubmitted Form are set out below (step 4 - 8 of Appendix B):

To correct a Forms data, FNSD recalls the original data of the resubmitted Form from the FIS database. FNSD captures the desired corrections. After corrections, FNSD selects an option to update the FIS database. The system then validates the Form’s data. If the entered Form’s data is correct, the system saves the data to the “Information” table in the “FISDATA” database of the FIS. The system subsequently removes the Form’s data from the batch’s table in the FIS database.

After the system validated the Form’s data, FIS clears the “FaultInfo” table in the “FISDATA” database. The data of all the forms that failed the validation copies from the batches’ tables in the FIS database to the “FaultInfo” table in the “FISDATA” database. If the validation of the Form’s data failed, the system does not remove the Form’s data from the batch’s table in the “FIS” database.

Part four: FNSD refers the Form back to the AD. If an AD reports a Form inaccurately on CBFET, FNSD sends a copy of the Form back to the AD to report it correctly. If a validation error occurred during the capture process FNSD sends the original Form back the AD for correction.

The list of the system's functions is as follows:

• Capture Form Or Repatriations. • Compile Standard, Custom Or Period Reports as well as make Enquiries. • Selecting to view data by date or by a specific table fields' criteria • Maintain ADs, Allowed Amount, Applicant, Currencies, MICR, Internal Users & External Users.

Compile an audit trail on applicant's transactions. • View the system's technical documents.

Forms Management Menu Repatriation Management Menu Standard Reporting Menu The purpose of this screen is to make it possible for a Capturing user to maintain (search, capture, edit and delete) Forms. A Capturing user is able to:

• Search for an existing Form. • Capture a new Form. • Edit a Form’s details. • Delete a Form.

The purpose of this screen is to make it possible for a Capturing user to maintain (search, capture, edit and delete) repatriations. This screen also displays the remaining allowed amount that an applicant may invest and the total repatriated amount for each applicant. A Capturing user is able to:

• Search for an existing repatriation. • Capture a new repatriation. • Edit a repatriation’s details. • Delete a repatriation.

The purpose of this screen is to make it possible for a Reporting user to draw standard reports. • Violation Reports

o All investment over the allowed amount

• Information Correct Reports o All correct investments o Repatriations

• Information Fault Reports o Invalid ID number o Invalid TAX number o Validation error



Forms Management Menu Repatriation Management Menu Standard Reporting Menu

• All Information Reports o Applicant o Users o Change Requests o ADs o MICR codes o All investments o Totals per month o Persons investing

Maintain Currencies Menu Maintain Authorised Dealers Menu Maintain Applicant Menu The purpose of this screen is to make it possible for an FNSD System Administrator to maintain (search, create new, edit and delete) currencies.

The purpose of this screen is to make it possible for an FNSD System Administrator to maintain (search, create new, edit and delete) Authorised Dealers and MICR codes.

The purpose of this screen is to make it possible for an FNSD System Administrator to maintain (search, create new, edit and delete) applicants.

Maintain maximum allowed investment amount screen

Maintain User Menu Audit Trail Menu

The purpose of this screen is to make it possible for an FNSD System Administrator to maintain (view, create new, edit and delete) the maximum allowed investment amount.

The purpose of this screen is to make it possible for an FNSD System Administrator to maintain the system’s users of both FNSD and ADs. The FNSD System Administrator must also be able to change an AD user’s password or lock/unlock any user’s access to the system.

The purpose of this screen is to make it possible for an FNSD System Administrator to view changes made to the database.

3.3.5 Foreign Loan System (FLS)

3.3.5.1 FLS Application for external use

Record New Loan Menu Enquire Loans Menu This is the section for recording a new loan. The record loan section is divided into three parts. The first two parts are the capture screens while the last part is the confirmation of the new loan created. The user can navigate back and forth to edit the details entered before the loan is confirmed.

• Part1: This is the first capture screen for the new loan. The screen is divided into three sections, Loan Identifications Details, Loan applicants/entities and the lender detail. • Part2: This is the second part of the Loan

capture screens. The screen is divided into the following sections:

o Loan Amount Details o Interest Rated o Proposed Repayment Details o Other Details o Terms and Conditions

• Confirm New Loan: On this screen the only thing that is needed is confirmation and the user may click on Save and complete to complete the loan. Should there be any changes that are needed; the user may click on the back button to edit.

This is the loan enquiries section. The user may do loan enquiries using one of the following options:

• Own Loan: Enquire loan number that belongs to the logged in Authorized Dealer.

• Other Loan: The user may enquire the existence of a loan number, and if they have additional access for it a link will be created to view the loan details.

• Applicant Name: Enquire using Applicant name. • Applicant ID: Enquire using Applicant ID • Application Number: Enquire using applicant number. • Lender: Enquire using Lender name • Transaction Ref: Transaction reference number – Enquire

using Transaction reference number and the loan number for that transaction will be returned.

• Draw Downs: Whenever the details of a loan are displayed the user will always see a sub Menu at the top of the page. The user can the use this menu to navigate to the draw down details for that loan.

• CFE Transactions: Whenever the details of a loan are displayed the user will always see a sub Menu at the top of the page. The user can the use this menu to navigate to the CFE transactions for that loan.

• Proposed Repayments: Whenever the details of a loan are



Record New Loan Menu Enquire Loans Menu

displayed the user will always see a sub Menu at the top of the page. The user can the use this menu to navigate to the Proposed Repayments for that loan.

• Repayments: Whenever the details of a loan are displayed the user will always see a sub Menu at the top of the page. The user can the use this menu to navigate to the Repayments for that loan.

• Interest Repayments

Reports Menu Admin Menu

• LIR – Loan Information Report: This is a report for an individual loan, the user will enter a loan number on the given text box. Once the user clicks on the view report button they will see a screen with report divided into four sections. The top section is the loan detail section. Below the top section there are the three data grids for the Repayments, Draw downs and Interest payments.

• FLA – Foreign Loan Anomalies: This is a report which contains all the loan anomalies.

• ODD – Outstanding Draw Downs : This is a report for all outstanding draw downs

• GDR – Loan per Dealer

• This is the administration section where an Administrator can view all users for their Authorised dealer. The Administrator can also add new users and also edit user details by clicking n the respective buttons.

• Add new User: On this screen the Administrator can add new users

• Edit user details: This is the screen for editing users of the system.

3.3.5.2 Application for internal use by FNSD

The FLS internal interface is a system that provides FNSD with a tool to enable them to capture new loan detail and maintain all the loan detail relating to draw downs, actual repayments, interest payments, proposed repayments, authorised repayments, loan applicants, loan authorised amounts, queries, and audit trail. The system also provides a facility with Loan reports as well as Cross Border Reports to generate statistical information.

The FLS internal interface has three different user groups; capturers, readers and administrators.

Capturer users

• Search, capture,edit, and delete forms • Capture new applicants by making use of the capture form screen • Search, capture, edit and delete repatriations

Reporting users

• Query a set of standard reports o Some reports requires a start and end date o Some reports requires a max allowed amount to be specified

• Request charts (the internal interface provides two charts)

Administrators

• The administrators of the internal interface will have access to all of the interface’s screens. Thus an administrator will be able to perform all the functionalities of capturers and reporters.

• Search, capture and edit users of the external interface o Reset external users’ passwords

• View the audit trail of the system



• View centralised tables: o Authorised Dealers o Branch Codes o Denomination o Domicile o Exchange Rate o Interest Rates o Interest Types o MICR Codes

• Search, capture, edit and delete a Foreign Loan • Search, capture, edit and delete Draw Downs for a Foreign Loan • Search, capture, edit and delete Actual Repayments for a Foreign Loan • Search, capture, edit and delete Interest Payments for a Foreign Loan • Search, capture, edit and delete Proposed Repayments for a Foreign Loan • Search, capture, edit and delete Authorised Repayments for a Foreign Loan • Search, capture, edit and delete Loan Applicants for a Foreign Loan • Search, capture, edit and delete Loan Authorised Amounts for a Foreign Loan • Search, capture, edit and delete query Management for a Foreign Loan • View Audit Trail for a Foreign Loan • CFE Enquire on Loan No

Foreign Loans Menu Record a Loan Consolidate Loans The purpose of this screen is to make it possible for a user to search for foreign loans by:

• Applicant • Loan Number • Lender • Applicant Number • Transaction Reference Number

On this screen the user will obtain a view of the Foreign Loan the user wants to maintain. There are four regions that contain relevant information.

• Queries: Contain the query detail if applicable to the Foreign Loan.

• Applicants: Contain the Applicant Detail of the Foreign Loan.

• Foreign Loan Detail: Contain a view of the captured Foreign Loan.

• Maintain Loan. Options from here: Draw Downs: The link will navigate the user to the “Draw Downs” Screen. The purpose of this screen is to make it possible for the user to maintain draw downs on the system. The following steps need to be followed when a user wants to maintain draw downs. Actual Repayments: The link will navigate the user to the “Actual Repayments” Screen. The purpose of this screen is to make it possible for the user to maintain actual repayments on the system. Interest Repayments: The purpose of this screen is to make it possible for the user to maintain interest payments on the system. The following regions will be loaded when a user navigates to this screen. Proposed Repayments: The purpose of this screen is to make it possible for the user to

When this link is selected the system will navigate to the “Record Loan” tab of the system and the “Record Loan“ screen will be loaded. This screen will enable users to record a new foreign loan on the system.

When this link is selected the system will navigate to the “Consolidate Loans” tab of the system and the “Consolidate Loans “screen will be loaded. This screen will enable users to Consolidate Loans in the system. The purpose of this screen is to make it possible for the user to consolidate loans with each other. Cancel Consolidate Foreign Loan: The purpose of this screen is to make it possible for a user to:

• Revert back the Consolidation of a Loan when a mistake was made • Search for existing loan number that needs to be cancelled consolidated TO



Foreign Loans Menu Record a Loan Consolidate Loans maintain proposed repayments on the system. Authorised Repayments: The purpose of this screen is to make it possible for the user to maintain authorised repayments on the system. Loan Applicants: The purpose of this screen is to make it possible for the user to maintain loan applicants on the system. Loan Authorised Amounts: The purpose of this screen is to make it possible for the user to maintain loan authorised amounts on the system. Query Management: The purpose of this screen is to make it possible for the user to maintain queries on foreign loans on the system (where access is required on a loan owned by another AD). Audit Trail: The purpose of this screen is to make it possible for the user to view the audit trail on a foreign loan on the system. Historic Audit Information: The purpose of this screen is to make it possible for the user to view the Historic Audit Information on a foreign loan on the system. CFE Enquire on Loan No: The purpose of this screen is to make it possible for the user to view the CFE information on a Loan No on the system.

Loan Reports Menu Cross Border Reports Codes and Rates Menu When this link is selected the system will navigate to the “Loan Reports” tab of the system and the “Loan Reports“screen will be loaded. This screen will enable the user to access different loan reports.

• Loan Reports o Loan Information Report

• Period Reports o Loan Reports o Anomaly Reports

• Month End Reports o Total Debt Maturity Report o Total Debt Report

Breakdown Loan Class o Total Debt Report

Breakdown Repayment Terms

o Exposure per Loan Class Chart

o Exposure per Repayment Terms Chart

• Draw Down Reports o Outstanding Draw Downs o Actual Draw Downs

• Loan Analysis Reports o Loan per Authorised

When this link is selected the system will navigate to the “Cross Border Reports” tab of the system and the “Cross Border Reports“ screen will be loaded. This screen will enable the user to access different loan reports. The purpose of this screen is to make it possible for a user to navigate to reports on the BOP-FDM File, the draw downs, actual, repayments and interest payments that came from SARBDEX.

• Inward Reports o Loan Numbers in BOP -

Inward (ALI) o Loan Numbers in BOP -

Inward and FDM (FDI) o Interest Payments in BOP -

Inward (IPI) o BOP - Inward not numeric

(NNI) o No Loan Numbers in BOP -

Inward (NLI) o Loan Numbers in BOP -

Inward and not in FDM (NOI) • Outward Reports

o Loan Numbers in BOP - Outward (ALO)

o Loan Numbers in BOP -

When this link is selected the system will navigate to the “Codes and Rates” tab of the system and the “Codes and Rates“ screen will be loaded. This screen will enable the user to access links to different codes and rates. The purpose of this screen is to make it possible for a user to navigate to interactive reports on Codes and Rates.

• Authorised Dealers • Bad Boys • Branch Codes • Denomination • Domicile • Exchange Rate • Interest Rates (create, update,

delete) • Interest Types (Create, update,

delete) • MICR Codes


http://srv13775.resbank.co.za/pls/exc_apex/f?p=300:177:3354548494949476::NO:::


Loan Reports Menu Cross Border Reports Codes and Rates Menu

Dealer o Loan per Branch Code o Loan per Applicant o Loan per Lender o Loan per Actual

Repayments o Loan Finalised or not o Loan Enquiry per AD

• Annual Loan Reports o Annual Loan Report o Annual Draw Down Report

per Loan Authority Date o Annual Draw Down Report

per Value Date o Annual Repayment Report

per Loan Authority Date o Annual Repayment Report

per Value Date • Annual Loan Reports

o Exposure per Denomination (Domicile) Report

o Exposure per Denomination (Loan Number) Report

o Exposure per Denomination (Application) Report

Outward and FDM (FDO) o Interest Payments in BOP -

Outward (IPO) o BOP - Outward not numeric

(NNO) o No Loan Numbers in BOP -

Outward (NLO) o Loan Numbers in BOP -

Outward and not in FDM (NOO)

• Inward and Outward Reports o Loan Numbers in BOP -

FDM (BTS) o BOP-FDM per period (BPS) o BOP-FDM per bank (BFB)

• CFE Enquire on Trn No

Administration Menu Documents Menu When this link is selected the system will navigate to the “Administration” tab of the system and the “Administration“ screen will be loaded. The purpose of this screen is to make it possible for the administrator to maintain internal and external users. Check the audit trail, give additional accesses and enquire all accesses to the system.

• Internal Users • User Groups • External Users: The purpose of this screen is to make it

possible for an administrator to: o Search for existing external users o Capture a new external users o Edit external users o Reset external user’s password o Delete external users

• Audit • Additional Accesses • Enquire all Accesses

When this link is selected the system will navigate to the “Documents” tab of the system and the “Documents“ screen will be loaded. This screen will enable users to access documents regarding the system.

• Technical Overview • Data Loading • Reporting and Graphs Setup • Audit

3.3.6 Data Exchange System (SARBDEX)

The SARBDEX II application performs file layout and data content validation checks by calling schemas via the web. The application also takes care of hashing and encryption for security reasons. Finally the application provides a log file of when the file was submitted, a reply received thereto as well as any errors in the file.

The files are submitted via a secure line to the SARB using the web or SWIFTNet. At the SARB the files are decrypted using the Reporting Entity’s password. A hash value is also created by the SARB and compared


http://srv13775.resbank.co.za/pls/exc_apex/?p=300:112:3040925631143669::NO::::


to the hash value supplied by the Reporting entity. If these two match a process kicks off that checks the file for errors. Only correct transactions will be stored on the SARB database.

All messages are submitted via a 128-bit encrypted line. Three levels of security are available and one of the levels must be activated:

(a) Password - a unique password.

(b) Encrypted password - a unique and encrypted password using the Blowfish algorithm.

(c) Encrypted hash value - the hash value of the message using the MD5 algorithm encrypted by the Blowfish algorithm.

3.3.7 Important notes about error handling

Errors are generated by different systems. Reporting Entities receive a response message, which indicate the type of error and the level where the error occurred. Data submitted will be routed through SARBDexII and then forwarded to the Oracle database if the file passes the SARBDexII validations.

To identify the level of error, Level 1 is SARBDexII related rejections and Level 2 is rejections from the Oracle database.

Level 1 rejection is a file rejection where the complete file is rejected and no processing of any transaction in the file takes place in the Oracle Database.

Level 2 rejections is on transactional level and the affected transaction only is rejected. Transactions which pass the Level 2 validations are stored on the Oracle Database.



3.4 Application Integration – Data Flow Diagrams Figure 13: Application Integration FRS Collection and Dissemination



Figure 14: Application Integration FRS Systems Interaction



Figure 15: Application Integration FRS Advance Queue System



Figure 16: Application Integration FLS Systems Interaction



Figure 17: Application Integration FIS Systems Interaction



Figure 18: Application Integration IVS Systems Interaction



Figure 19: Application Integration PIRS Systems Interaction



4 Files and Transactional Volumes This section of the document addresses the volumes that has been encountered for the period Sept-2013 to June-2015.

Month File Count Transaction Count Total Size (GB)

Sep-13 33 476 3 366 498 5.40

Oct-13 32 925 3 951 186 6.53

Nov-13 28 650 3 837 989 6.33

Dec-13 30 589 3 837 649 6.44

Jan-14 31 943 4 119 933 6.96

Feb-14 32 379 4 101 957 6.42

Mar-14 31 685 4 211 851 6.38

Apr-14 31 228 4 203 170 6.51

May-14 33 564 4 601 542 6.95

Jun-14 34 282 4 388 451 6.63

Jul-14 37 487 4 954 716 7.63

Aug-14 31 555 4 233 736 6.32

Sep-14 33 684 4 640 228 6.91

Oct-14 35 841 4 988 638 7.59

Nov-14 32 679 4 578 676 6.77

Dec-14 37 243 5 282 318 7.89

Jan-15 35 278 5 045 169 7.65

Feb-15 31 577 4 395 976 6.50

Mar-15 34 838 4 867 905 7.24

Apr-15 35 081 4 777 566 7.04

May-15 37 302 4 974 545 7.63

Jun-15 37 855 5 012 881 7.57

Average 33 688 4 471 481 6.88
