Skip to main content

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:

  • Firewall

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

  • Routing

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.

  • Handling of brute-force attacks

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.

  • Throttling

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.

  • Load balancing

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.

  • Parsing the request

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.

  • Sending response

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

  • Logging the API usage

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:

  • Customer login

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.

  • Customer registration

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

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

  • Secure storage and retreival of customer's personal data

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.

  • Data obfuscation and removal

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.

  • Session management

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.

  • Device management

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

  • Permission management

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

  • Encryption key exchange

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:

  • Holding the ledger

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.

  • Handling financial messages

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.

  • Handling fees

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.

  • Advanced authorisation decision making

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.

  • Micro loans

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:

  • External ledger

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.

  • Internal 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.

  • External ledger with decision option

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:

  • The cardholder initializes the transaction on POS terminal
  • The terminal sends transaction to the scheme and processor
  • The processor does the transaction processing and sends the reqeust to the Syllo
  • Syllo handles the request by proxying it to the ledger service (and few other services too, for logging and transaction storage)
  • The ledger service calculates fees, checks conditions set by the cardholder and if all adds up approves the authorisation
  • The result from the ledger service is sent back to the processor
  • The processor approves/rejects the transaction based on response from Syllo

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:

  • Payment device issuance
  • Activation
  • 3DS registration
  • Loading money on the device
  • Locking/unlocking device
  • Show/change PIN on device
  • P2P transfer between devices
  • Device linking/unlinking

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:

  • Realtime transaction feed

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.

  • Bulk transaction import

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.

  • Pull the transactions from processor's APIs

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:

  • Transaction service parses data and transforms it into a common format
  • Parsed transaction data is stored in Syllo's database
  • Response returned to client has the same structure regardless of data format returned from processor

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 metrics
    • Customer acquisition
    • Customer behaviour
    • Customer spending
  • Account metrics
    • Accounts created per time
    • Money in/out tracking
  • Payment device metrics
    • Issuance tracking
    • Device activation tracking
    • Spending per device
  • Transactional metrics
    • Transaction count per time
    • Transaction value per time (average and cumulative)
    • Transaction categories (per MCC codes)
  • API usage metrics
    • Usage from mobile/web clients
    • Usage per platform (Android/iOS/web)
    • Number of installations/uninstallations

Customer care service​

This module provides following functionalities:

  • Customer management - disabling/enabling access to specific customer
  • Fraud handling - browsing the customer API usage data and generating reports for authorities
  • Customer identification by using challenges
  • Basic tracking of customer care tickets with reminders

Notification service​

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

  • Push notifications

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

  • E-mail E-mail notifications are used for password reset procedures or as an additional OTP channel.

  • SMS SMS notifications are mostly used for end-users who don't own smartphones and where SMS is an only option to deliver a message.

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):

  • Terms and Conditions (global o per account/paymen device basis)
  • Privacy Policy
  • FAQ

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