Account Visibility

Introduction

This document provides a comprehensive overview of the Account Visibility project. The project delivers a unified, scalable, and supportable solution for clients to manage the visibility of their accounts across all Investec business units.

Background

The account visibility feature originated as a tactical solution to security threats like hijackings, where clients could be forced to expose their banking information. This solution allowed clients to hide their SA Private Bank and Wealth accounts on Investec Online, with changes reflecting in the Global Private Client App.

Problem Statement

The existing tactical solution must be extended to other products and account types, including UK and Mauritius accounts. The current implementation has limitations that hinder broader adoption and operational efficiency. The goal is to implement a future-proof architectural solution, enabling various business units to manage their own account visibility settings independently.

Objectives

• Implement the preferred architectural solution for account visibility.
• Empower other Business Units (BUs) to utilize this feature for their respective accounts.
• Ensure the scalability and maintainability of the solution.
• Remove the dependency on the One Place team for managing account visibility settings.

Preferred Implementation Flow

1. Client Action: A client logs into Investec Online (IOL) and navigates to "Edit Preferences" to show or hide their accounts.
2. Dashboard API Request: The Dashboard API processes the client's request and saves these preferences to the Settings API.
3. Settings API Storage: The Settings API stores the account visibility preferences.
4. Frontend Data Request: Concurrently, the frontend (IOL/App) calls the Digital API layer for account data.
5. Digital API Processing: The Digital API layer routes these requests to the respective business units' BFFs (Backend For Frontend) or portfolio endpoints.
6. Account Retrieval: The portfolio endpoint retrieves the client's accounts from downstream host systems.
7. Schema Application & Filtering: This data passes through a settings layer within each BU's account settings API. A schema defines whether each account is hidden or visible, and the data is filtered based on the client's stored preferences.
8. Display: The Dashboard API returns the filtered accounts for display on IOL or the Private Client App.

Layers

The Account Visibility project is structured into three main layers:

• Nuget Package
• API Layer
• Dashboard Layer

Project Resources

• Confluence Requirements: Account Visibility - Requirements
• Figma Designs: Web Source of Truth

Benefits

• Data Accuracy: BUs can update their own account settings, reducing client confusion from outdated views.
• Improved Architecture: Logic moves to a dedicated back-end layer, enhancing maintainability, scalability, and feature delivery speed.
• Enhanced Client Support: APIs and a potential portal offer unified views, empowering support teams for faster resolutions.
• Reduced Operational Dependency: Self-service for BUs reduces bottlenecks and improves autonomy.
• Increased Development Efficiency: Centralized account data access reduces effort and ensures consistency.