NAV

Syllo

Syllo powers the logic and integrations of the banking and payments supply chain. It provides customers with access to the required services and allows them to create custom business journeys that best serve their current and future business objectives, even if they use multiple suppliers.

Syllo fits between service providers (card processors, kyc and agency banking providers or similar) and mobile/web front-end applications which present the data to the end users. Syllo can be also placed behind a custom backend solutions, which will use the Syllo as a proxy layer to simplify their backend service development and speed up the delivery.

Shortcuts:

Syllo for FrontEnd

Syllo exposes a set of API methods ready for direct usage by mobile/web applications. Those method provide basic functionality required by front-ends to be able to build a user friendly UX/UI with following funcitonalities:

When configured for a front-end usage, the Syllo will expose an endpoint which will be accesible by the mobile and web applications. The endpoint uses TLS encryption for all traffic, combined with additional RSA encryption when required.

The behaviour of API endpoints is controlled by the initial configuration on Syllo deployment, but also can be overriden on-the-fly through the admin interface.

Syllo for BackEnd

When used behind another backend, as a proxy, Syllo provides following benefits:

How it works?

In it's core, Syllo is a data processor and aggregator. It collects data from multiple sources, process it, stores it and proxies it to other locations when needed/requested to.

An initial step in data processing is data transformation, done by passing data to specific adapters and abstraction layers in order to transform data into more usable/generalized format. The abstraction layer enables Syllo to store data from multiple vendors and to present it to the API users in a common format.

The web service response received from vendor, either in JSON or SOAP format is converted to an abstract format which contains a specific set of attributes most likely to be used by the API consumers. Those attributes are stored in a database layer, which intelligently chooses the caching strategies based on a vendor or on a data type.

The data processing service handles sensitive data in a PCI compliant manner. If the client is not PCI compliant, the data processing can be adjusted to avoid storing/transmitting and processing affected data.

Syllo Components

Syllo is built as a scalable platform, split into following layers:

The API layer exposes web service calls for external usage. It parses and validates requests, proxies the requests to the core layer and returns response to the API client.

Core layer contains all the logic necesary for Syllo to work. It's split into serveral services, each in charge of the specific niche.

Most vendors require a reverse connection back to the backend - a way to post data back into the system. This is handled by the external layer. It receives data from vendors, parses and process it by using core services.

The data processed by Syllo is stored in both relational and non-relational databases. The type of the data, availability and performance needs are the main criterias which dictate the type of underlying databases.

Core services

API service

The API service handles the requests from clients (either mobile/web applications or other backends). The actual request handling includes several steps:

The service uses its' own firewall rules to prevent access to non-whitelisted API consumers.

Based on the request URL and type of the payload (JSON or XML), the API service routes the request to the specific sub-service in the system.

Every API call can be configured to suppor limited number of retries. After all retries are used, the system can be configured to lock the customer, account or payment device and inform both the customer and customer care agents about the possible security issue.

Some of the API endpoints are triggering business logic which requires multiple calls to vendor APIs. In those cases, overusage of Syllo's API calls can lead to heavy traffic to the vendor's API. The API service can be configured to throttle actions which may cause those issues.

Although the load balancing is handled on infrastructure level, the API service is able to detect increased traffic on one or more specific services and can instruct the infrastructure provider to scale up.

The API service can be configured to support multiple types of requests, JSON, XML, Messagepack. Custom data formats and additional encryption can be added if needed.

The API service detects which data format is requested by API consumer and returns the response in that format.

API calls can be logged in order to provide enough data for analytics or fraud investigation. The logging service will prevent storing any sensitive data in logs.

Authentication service

Authentication service provides all functionalities related to customer authentication, authorization, session management, permission management and similar. Main functionalities include:

The service validates customer credentials and issues a session token after a successful login. The token expiration can be configured and token can be revoked at any moment, which efectively destroys the session of the user.

During the registration, the service collects all needed data about the customer and creates a customer's account in the system. Based on system configuration, customers can be allowed to access the system immediately, or the system may be configured to ask them to undergo a KYC procedure before that.

Password reset includes sending a secret using another channel - either email or SCA device. All passwords are encrypted using bcrypt algorithm.

The service stores all sensitive customer's data. Every data retrieval is logged, with a reason, IP address and few more attributes which can be used to identify data breaches.

If requested by client, the service can remove all references of the personal data. Data is obfuscated in a non-reversible way, which enables customer care agents to browse existing transactions in case fraudulent behaviour is detected after the actual data removal.

The service stores session data for every access to the system. Along with sessions, all user actions are logged. The logging itself doesn't store any sensitive data - it stores minimal data set required by fraud detection tools and teams to be able to identify and resolve fraudulent behaviour.

Every device used by customers to access the API is logged.

The service handles different permission levels per customer. API functionalities can be limited based on permissions configured in the system.

In case when SCA is required, or any case where advanced data security in transport is required, the Authentication service handles key exchange and storage.

Ledger service

Syllo's ledger service is capable of managing the ledger for payment devices and accounts, with advanced customization capabilities.

Ledger functionalities

The main functionalities of the ledger services are:

Syllo tracks the changes on ledger and updates the ledger based on both internal and external events. Internal events include scheduled fee collections, loads and unloads through web service calls, balance adjustments and similar. A real-time transaction from the processor is an example of external event, which affects the balance if approved.

The ledger service handles all messages received form the processor (autorisations, reversals, etc.) and updates the ledger accordingly. The ledger service can use its' functionalities to approve or decline authorisation, based on current ledger state.

Every payment device product can be configured to have multiple types of fees (weekly, monthly, non-spending fees, specific web service fees, exchange fees). The ledger service is calculating fees and including them in authorisation decision.

The ledger service can be configured to decline authorisations based on a specific criteria related to the device itself or to the device holder. For example, user can decide to set a daily spend limit and the ledger service will include that criteria in decision making process.

A payment product can be configured in a way to enable micro loans - in that case the ledger service will allow overspending on the account in the defined limits.

Ledger handling

When it comes to ledger handling, there are two available modes:

In this mode the ledger is being held by the vendor (processor). Syllo pulls the ledger info and updates it regularly but it doesn't have any impact on the actual ledger.

Syllo holds the ledger and serves as a single point of thruth. In this case processor has to send real time data to the Syllo as the ledger service is the one which will decide wether there are funds on the payment instrument or not.

This approach is similar to the external ledger approach, but with an option for Syllo's ledger service to affect the decision. In this case, the processor will decide wether the transaction is approved, but Syllo has the option to decline transaction based on internal rules.

Ledger service and vendors

Ledger service is tightly coupled to processor which handles the card processing. If the Syllo's ledger service is in charge of making authorisation decisions, the processors are required to send real-time financial messages (authorisations and reversals) and to handle responses from the Syllo.

Looking at the standard POS transaction on card, the procedure would be the following:

As there is no standardized data format used in communication of the financial messages from processors, Syllo needs to be configured to be able to understand the data format for a specific processor. The configuration is made by creating a custom addapter which will addapt the message to a format which is understandable by all Syllo's services.

Payment device service

Payment device service handles issuance and usage of payment devices - cards, virtual cards or wearables. The available functionalities heavily depend on the processor's APIs, but the main are:

In order to be able to issue payment devices by using the service, Syllo needs to know which device products are available and which processor is in charge of the every product. When client tries to issue a card for example, the system detects which processor should be used, handles the API calls to the processor and stores the card reference internally. From that point on, API consumer is using the internally stored version of the card. Once a side effect action is required (card lock, show PIN), the service resolves the processor for the card and calls appropriate APIs.

Transaction service

The transaction service handles storage and retrieval of transaction data.

There are following ways for a transaction to arrive in Syllo:

In this approach, the processor is sending the transactions in real time. The most common protocol used is HTTP using POST method. In this case, the transaction service parses the received data, stores the cached version in its' own database and informs other services that the new transaction arrived.

Some processor prefer to send all transaction data in one bulk, on hourly or daily basis. In this case the transaction service parses the bulk files, stores data and notifies other services.

This approach assumes that all transactions will be pulled on demand directly from processor's APIs. Depending on number of Syllo's clients, this approach can create a large number of concurent web service calls to processor's infrastructure. Although Syllo has protection in place, which ensures that all pulled transactions are cached to avoid high load on vendor's services, this approach is rarely used and considered bad practice.

All three approaches above have following in common:

Multicurrency service

This service handles basic FX functionalities, such as exchange calculation, exchange rate storage and synchronisation. It can be configured to use specific APIs to pull rates from, or to use external API methods to calculate exchange.

KYC service

KYC service handles KYC/KYB verification of the customers. The admin can configure which checks should be run (PEP, SIS, eKYC, Document check), what are the triggers (registration, profile change) and what actions should be run after a successful/partially successfull or failed KYC process.

Analytics service

Analytics service is repacking the aggregated data in a way which is suitable for analytics purposes. It exposes a large number of API calls which can be used for rendering graphical representations of all key metrics. Bundled with the Syllo's admin interface it creates a powerful analytic tool which helps sales and marketing teams to meet their goals.

Some of the available metrics are:

Customer care service

This module provides following functionalities:

Notification service

Notification service handles the comms to the end-customers. It supprorts following channels:

By using Firebase and/or Apple's Push Notification Service (APNS), the Syllo is able to send notification directly to the customer's device.

Legal service handles storage, presentation and versioning of the legal documents required for programme to be fully compliant. These include (but are not limited to):

This service enables versioning the documents and handles comms to customers on new version release.

Syllo APIs

Syllo exposes a large number of api calls, grouped into following groups:

Front API

Front API is used by front-end clients. This is a simplified version of the API which enables easier integration on front-end while maintaining high level of customizability.

Key concepts

The key concepts for the API are:

Front API functionalities

Front API functionalities include (but are not limited to):

Front API definition can be found here.

Extended API

The Extended API can be used by both front and back-end clients. It contains a large set of API methods which can be used for fine tunning of the system.

Backend API

Backend API exposes all Syllo functionalities. It's not meant to be used directly by end-users, but by client's existing server application.

Backend API definition can be found here.

Data storage and backup

Data storage is handled by Syllo's database laayer. Data is segregated in multiple databases to provide better scalability and performance in general. Type of database (relational or document based) is selected based on use case and performance needs.

Data transfer between databases and core services is encrypted. The data is encrypted on rest too, with strong RSA encryption, which ensures that data can't be compromised in case of direct access to physical storage.

Data integrity and availability is ensured by using following principles:

The underlying database storage engine is distributed in multiple regions, enabling the engine to recover in case of outages in some of the regions.

Syllo can be configured to use read/write replicas in order to boost performance.

Database backups are done in defined periods (daily/weekly/monthly). All backups are encrypted on rest.

Syllo deployment

Syllo can be deployed on any hosting environment which supports containerized architecture (Kubernetes, docker). We prefer to deploy it on AWS, as AWS offers unique abilities to deploy, run and scale enterprise level applications.

Every Syllo instance is deployed in a separate network, physically separated from other Syllo instances. This approach makes easier to clients to be inline with the regulations and data security policies.

Tech stack

NodeJS

Backend services are built with NodeJS as a main programming language. NodeJS enables us to create performant asynchronous web services. Its' event driven I/O model makes it easier to create scalable network solutions, which is very important when dealing with large volume of financial data.

Docker

We are using docker to containerise the Syllo into many container which can scale separately. Every containerized service covers specific set of Syllo's functionality and docker (together with Kubernetes) makes the deployement and running of the application faster and more straight forward.

SQL

SQL databases are used for relational data storage. The type of database depends on underlying hosting provider capabilities (AWS Aurora with MySQL dialect, SQL server, PostgreSQL). The financial data is relational in its' core and fits well with SQL databases. By carefylly using indexes, redundant columns and tables and other data optimisation techniques SQL databases proved to be reliable and performant in all Syllo's use cases.

NoSQL

NonSQL databases are used for storing large sets of non-relational data. They are mostly used for logging or for storing data in intermediate format before processing and storing the data in relational database. Their abilities to store and query non-structured data makes them perfect for fast querying through the data when prompt investigation and report generation is needed.

Microservice architecture

Syllo's functionalities are split into several microservices. Every microservice follows following principles:

Every microservice has specific set of functionalities and responsibilities which don't interfere with other microservices.

Every microservice is responsible for data it uses for its' functioning.

In case of higher load every microservice will scale for itself. This reduces operating costs and enables the system to scale faster.

Microservices are hosted in their own containers. In case of brute-force attack and outage of a specific service, no other services are affected and affected containers can be easily replaced.