Table of Contents

INTRODUCTION 3

System Context 3

System Integrations 4

Component View 5

HIGH LEVEL ARCHITECTURE WITH SECURITY CONSIDERATIONS 7

TRANSACTION PROCESSING AND SETTLEMENT FLOW 10

INFRASTRUCTURE SPECIFICATIONS 11

Test environment specifications 11

Live environment specifications 11

INTRODUCTION

The Direct Card issuer platform is designed to process online and offline card transactions. The platform is deployed within  a financial institution’s infrastructure and fully managed by the bank’s personnel .  This document provides context of the solution’s architecture and dependencies. It’s audience is technical teams that would be involved in the day to day maintenance, troubleshooting and configuration  of the platform post deployment. 

System Context

Open

The super merchant / agent integrates with the bank through the AptPay DCIR platform. This provides capability for transaction processing for On-Us transactions by the bank as validated and routed by the super merchant. The DCIR platform is integrated with various internal bank systems to achieve transactions and settlement processing. TeamApt, Super Agent and Bank users interact with the DCIR platform. 

System Integrations

Open

The DCIR platform interacts with the following internal bank systems

• Switch Front End Processor (FEP) - To facilitate real-time transactions processing. Debit account holder for transactions authorization

• Core Banking System . For settlement and disputes refund processing. Integration to the CBA is achieved through middleware APIs for intra-funds transfers and transactions status requery

• Email SMTP gateway. For email delivery to users who interact with the platform. Send reports and general system alerts

• Active Directory. For centralized management and access of users 

Component View

• Aptent: This component handles real-time transaction processing.  It validates, logs and authorizes transactions with requests sent to the Banks FEP processor. It receives requests from super merchants/super agents. 

• RealTime Database: Relational database that Aptent interacts with. Stores transactions processing logs for later synchronization to the backoffice database

• Backoffice Database: Relational database used for reporting, dispute processing and settlement needs. Transactions from the real-time database are stored within this database.

• Backoffice Management Service: A collection of secure backend API services that interact with the backoffice database to retrieve transactional data and manage the platform.

• Backoffice Cron service: A collection of background jobs that aide with the processing of resource-intensive events or scheduled tasks around settlement, file upload processing and system alerts via email. This service interacts with the back office database.

• User management service: This identity management service is used to manage system users who interact with the DCIR platform.  

• User Management database: Holds user information as well as authorities associated with roles for the DCIR platform

• Backoffice Web Portal: A web portal used for system administration, report retrieval, dispute resolution, and extended user management. Users access is through role-based access control.  The portal is publicly accessible over the internet to allow super agent users to view reports, disputes, and transactions from a front-office perspective. 

• Redis:  Cache server used to save information in a key-value format for efficient and quick information retrieval.

N/B: Detailed description of key component, services and data dictionary is provided within separate documentation to be shared with the bank

HIGH LEVEL ARCHITECTURE WITH SECURITY CONSIDERATIONS

Key points to note on the DCIR Architecture:

• The AptPay DCIR platform is deployed within the financial institution’s environment. Agnostic of cloud or on-premise data centers

• The deployment is based on a 3-Tier architecture with application , data and web tiers segregated.

• The Realtime database and Backoffice relational database are in two distinct hosts.

• Connectivity between the bank and third parties such as super agents is strictly through site-to-site VPN connectivity

• Access to resources within the AptPay real-time service is authenticated before processing transactions 

•  Super agents users interact with the DCIR platform through a publicly accessible and secure administrative web portal. This is also accessible to bank personnel with role based access for both groups of users. 

• Integration points between the AptPay DCIR platform and individual bank systems adheres to guidelines and security requirements established by the bank. 

• Storage and logging of information within the AptPay DCIR platform adheres to PCI-DSS standards  and considerations. 

• Sensitive records such as Card PAN, OTPs, and passwords must are masked when inputted/displayed. Card data is not stored (PCIDSS requirement) and protected from unauthorized changes

• External Application Programming Interfaces (API) calls are  authenticated before data retrieval with API calls retrieve data in the expected sequence and format

• Password Policies

  • All Users are required to generate/own their passwords for access to system components and data. 

  • Passwords are rendered unreadable during transmission and storage on systems using strong cryptography. 

  • All default system or application passwords are disabled or changed, and ownership of such passwords is ascertained. 

  • Password resets require Users’ identity to be verified before processing. 

  • First-time passwords shall be unique for all Users and require change at the first logon. 

  •  Inactive User accounts shall can be removed/disabled after N days of inactivity. 

  • Passwords must be at least eight characters in length and consist of both numeric, uppercase, and lowercase alphabetic, and special characters. User passwords shall expire after 90 days. 

  • Password reuse must not include the last four passwords used.

• Authentication:

  • All authentication is accomplished through user-Ids and passwords

  • Each User must be assigned a unique user-ID, the same User-ID shall not be shared among multiple Users

  • Reuse of user IDs is avoided; 

  • Shared user-IDs and/or passwords must not be issued to multiple users. 

  • Default user-IDs and passwords for software and systems must be disabled or changed (if it is not possible to disable default user-ID)

• Auditing

  • Sufficient audit logs are captured for critical system Users and administrators’ activities shall be maintained for all operational systems and system applications. These are logged within the centralized identity access system. 

  • Audit Trail are implemented on applications, databases, Application  Programming interfaces (API)

  • Audit logs capture: -User ID/ name, -Timestamp, -IP/MAC address, -computer name (where applicable), -Date of activity, -Details of Modifications/update/edit, -status of activity/update/edit (success, failed), etc. -Previous data, and new data.

  • Audit trail are also implemented for changes/modifications  of users’ profiles, access rights

  • Depending on criticality, API activities are logged (request  and response time, authorization, results of API authentication attempts, and message). Sensitive data like login credentials are  not logged.

TRANSACTION PROCESSING AND SETTLEMENT FLOW

INFRASTRUCTURE SPECIFICATIONS

Test environment specifications 

Live environment specifications