Modern Architecture

#digitalharbour features modular design, which means the choice for the customers, and possibility to acquire only needed parts of the system. #digitalharbour software has been designed in accordance with SOA and Microservices architecture principles, that are discussed more in detail in this article.

Online Bay

Solution has been developed according to the Service Oriented Architecture principles, therefore it is multidimensionally scalable. All core services have been designed in the form of separate Microservices, featuring REST API to communicate with the other modules of the system and external world.

This approach enables the following benefits:

  • Improved scalability, easier gradual deployment
  • Easier QA – services are smaller and faster to test
  • Fault isolation – service failure doesn’t mean the whole system failure (may not be valid for some services like Auth for example)
  • Elimination of long-term commitment to a technology stack – microservices can operate and the system expansion can be done with more advanced technologies in the future

The following figure shows internal solution architecture of the ONLINE BAY, showing 4 mainservices, that the systems operates on, each of them equipped with REST API:

OnlineBayBankScheme

Client Core: containing the main business logic and consolidating information and atomic-level functionality, received through the integration layer from the backend systems of the bank, forming then higher level functions, published on the API gateway later on.

Admin Core: where all administration tasks and tolls are setup. Web user interface for Core-Service business administration like configuring operation rules (allow, deny, commission, limit, alert, authenticate), client profiles, client operations. Admin-UI API can be referred by the bank CRM system for the needs of call center, for example – TBD during integration.

AUTH Server: our own N-factor authentication service, responsible for client credentials life-cycle: registering, managing password, activating new roles, describing current roles– can be easily replaced by bank standard Gemalto or Vasco, for example. If there is no standard authentication service at present, our Auth microservice can be successfully used for this and possibly other systems of the bank. Supported OAUTHstandard.

Client API Gateway: full-featured client RESTful API, suitable to satisfy most demanding external application or system. Comprehensive API for all clients needs as authentication, profile management, obtaining contracts, making all type of financial operations, service operations, getting operations history, contracts history, etc. Completely covering PSD2 compliance needs.

AutoBPM and e-Purse

AutoBPM and e-Purse have been developed with the use of the latest technologies and under SOA architecture principles. All core services have been designed in the form of separate services, communicating via internal bus with each other. This approach enables the following benefits:

  • Improved scalability, easier gradual deployment
  • Easier QA – services are smaller and faster to test
  • Better segregation – services can be designed and maintained separately

thrift

Core: containing the main business logic of the system, BPM process logic, Wallet processing logic, the image library for logos, original documents etc. Core is extendable. Extension modules have been designed using modern programming technologies and connect to the Core via API protocol. Extension modules can be also used for external systems integration, data analysis tools, reporting software, data processing instruments etc.

Admin Core: where all administration tasks and tolls are setup.

AUTH Server: our own authentication services, responsible for client credentials life-cycle: registering, managing password, creating and managing roles etc.

Web UI: separate from Admin UI, connected to the core via Web services

Client API Gateway: full-featured client Thrift API. Comprehensive API for all client needs and external upstream systems connection.

OS and Databases: the system is database and OS independent.

e-Purse service architecture

e-Purse service architecture scheme displaying various possible connections and configurations of the e-money infrastructure is show on the below scheme with two e-money issuer banks and few merchants.

epurse_arch

General comments to the architecture:

  • Processing center is integrated with the bank(s) via web-services HTTPS TSL1,2 – secured channel
  • When the issue or settlement transaction is happening, e-money processing side is immediately reflecting the results on the user wallet(s)
  • the issue or settlement transaction will also generate a notification, that will be sent via web services to the Core Banking System. There is a choice of action on core banking side: if legislation requires an immediate reserve of e-money with cash, then simultaneous transaction must be executed: debit cash/credit e-money reserve account. If there is no requirement of an immediate reservation, the bank may establish certain transaction volume limits and execute clearing between cash and reserve overnight, or upon reaching transaction volume. Implementation of both options is the subject for respective integration phase
  • e-Purse will provide all needed reporting for the banks on both issue and settlement transactions. It will also provide transaction history for the individual wallet owners, both clients and merchants.

Please let us know if you want to learn more about #digitalharbour products: