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:
- Authentication
- KYC
- Customer data management
- Creating of accounts and ordering of payment devices (cards, wearables)
- Activation, locking/unlocking, show/change PIN on payment devices
- Transaction display with spending analytics
- Real-time push notifications for every transaction
- P2P payments
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:
- Syllo abstraction layer enables the backend to use the same API methods and data structure for several diferent vendors
- Syllo will aggregate data from multiple vendors and proxy it in a generalized format back to the backend
- The transaction parsing service in Syllo parses the realtime transaction data and proxies it back to the backend
- The Syllo's event service notifies the backend when any asynchronous action happens
- The Syllo's database stores data in a PCI compliant manner
- If needed, Syllo exposes direct access to vendor services by proxying the request from the backend to the vendor directly. A secure secrets storage is used in order to store API keys and other credentials to avoid having them transferred between the customer's backend and the Syllo
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:
- API layer
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
Core layer contains all the logic necesary for Syllo to work. It's split into serveral services, each in charge of the specific niche.
- External layer
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.
- Database layer
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:
- 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
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.
Syllo APIs
Syllo exposes a large number of api calls, grouped into following groups:
- Front API
- Extended API
- Backend API
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:
- Expose simple API calls to enable basic set of functionalities to the front-end users
- Controll the format of the data sent to the front-end clients and ensure that the data is in compliance with the latest regulations
- Significantly reduce both amount of work and delivery time on client-side
- Controll the data flows between the different vendors and front-end applications in a manner which protects the vendor's API endpoints from overusage, which further lowers costs of the programs
- Allow end clients to use multiple vendors based on price, territory or specific programme requirements
Front API functionalities
Front API functionalities include (but are not limited to):
Authentication/Authorization
Customer account functionalities
- Create account
- KYC (with document upload)
- Accound data management
- Session tracking
Payment account functionalities
- Create payment accounts
- Lock/unlock payment accounts
- Transfer money between payment accounts
- Link devices to payment accounts
Payment devices (cards and wearables)
- Ordering of payment devices
- Management of payment devices
- Activation
- Lock/unlock
- Show/Change PIN
- Link device to a specific account
- Multicurrency
Statements
- View transactios per customer account, payment account, device
- Show spending analytics
- Group transactions by country/category
- Report transactions as non-recognized
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:
- Data is stored on multiple locations
The underlying database storage engine is distributed in multiple regions, enabling the engine to recover in case of outages in some of the regions.
- Replicas
Syllo can be configured to use read/write replicas in order to boost performance.
- Regular backups
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:
- Microservice is strictly scoped
Every microservice has specific set of functionalities and responsibilities which don't interfere with other microservices.
- Microservice manages its' own data
Every microservice is responsible for data it uses for its' functioning.
- Microservice is scalable
In case of higher load every microservice will scale for itself. This reduces operating costs and enables the system to scale faster.
- Microservices are decoupled on infrastructure level
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.