The Fexco Secure Transaction Service (STS) is a section of the Fexco Central API in charge of offer a set of services related to guarantee the compliance of financial transactions. We'll review here a section of the used model related to the Compliance Request of transactions.
It is composed by several components:
It is still a work in progress but we hope to release our first version pretty soon.
The areas covered by the STS are critically important in financial systems:
The set of the STS services covers most of the compliance and validation needs in regular transactions across different businesses and tenants. This is the list of main services available through the STS API:
The STS follows exactly the same architecture with which the Fexco Central API is being built. So, its integration is completely seamless allowing to re-use all common services in the Computing and Delivery Platforms (e.g. Log Analytics, ACL, scalability, etc).
This post will describe shortly the used model in the STS for the Compliance Request (marked in red in the diagram above) handling the validation and compliance of financial transactions. The Compliance Request depends upon the Compliance Flow defined for each business. A Compliance Flow consists of a sequence of steps regarding validation and rules.
The basic request is called "Compliance Request" and contains several sections covering all the expected cases. Some information as the correlation ID, etc is mandatory as part of the Central API.
The general request/message (it uses HTTP and AMQP protocols, provided by the Central API) contains all these sections that can be populated or not. The STS analyze the request/message and acts accordingly to the received information.
This model is a bit more complex than the others but it is justified because it provides a full context of a transaction and the holder involved. The Fraud Detection process involves payment media, a customer, address, data about the transaction, etc. What we get is a prediction about the probabilities of detecting a possible fraud attempt.
Please not the Transaction service uses the same Transaction request model included in the Fraud Detection model.
This service is more straightforward as it requires personal details and related addresses.
The STS is really close to it first release unifying the services for Compliance across different and heterogeneous businesses and tenants. The integration in the API provides full traceability, log analytics, integration in the alerts and notifications system, gets scalability and insights features and much more from the architecture in our Computing and Delivery Platforms. Our next steps are:
Thanks!
A General Overview of the STS
It is composed by several components:
- Customer Registry (general business-cross scope) with validated information and kept up to date
- Validation Flows Management
- Proof of Identity documents
- Transaction Data Warehouse (general business-cross scope)
- Fraud Detection for financial operations
- KYC (Know Your Customer or validation of personal details like addresses, card IDs, etc)
- Payment media validation (e.g. credit cards, debit cards, etc.)
- Address verification (e.g. from provided postcode)
- Anti Money Laundry Compliance Rules Engine
- Reporting
It is still a work in progress but we hope to release our first version pretty soon.
The areas covered by the STS are critically important in financial systems:
The set of the STS services covers most of the compliance and validation needs in regular transactions across different businesses and tenants. This is the list of main services available through the STS API:
The STS follows exactly the same architecture with which the Fexco Central API is being built. So, its integration is completely seamless allowing to re-use all common services in the Computing and Delivery Platforms (e.g. Log Analytics, ACL, scalability, etc).
The Compliance Request Model
This post will describe shortly the used model in the STS for the Compliance Request (marked in red in the diagram above) handling the validation and compliance of financial transactions. The Compliance Request depends upon the Compliance Flow defined for each business. A Compliance Flow consists of a sequence of steps regarding validation and rules.
The basic request is called "Compliance Request" and contains several sections covering all the expected cases. Some information as the correlation ID, etc is mandatory as part of the Central API.
- Business Information. Basic information about the tenant and business. Needed for multi-tenant APIs.
- Fraud Detection. Requests for the prediction of possible fraud attempts.
- KYC Request. Validation of data about customers (previous to their registration in the Customer Registry)
- Card Validation. Validation and retrieval of information about a card (type, brand, financial entity, currency, etc.)
The general request/message (it uses HTTP and AMQP protocols, provided by the Central API) contains all these sections that can be populated or not. The STS analyze the request/message and acts accordingly to the received information.
The Fraud Detection Model
This model is a bit more complex than the others but it is justified because it provides a full context of a transaction and the holder involved. The Fraud Detection process involves payment media, a customer, address, data about the transaction, etc. What we get is a prediction about the probabilities of detecting a possible fraud attempt.
Please not the Transaction service uses the same Transaction request model included in the Fraud Detection model.
The KYC Model
This service is more straightforward as it requires personal details and related addresses.
Next Steps
The STS is really close to it first release unifying the services for Compliance across different and heterogeneous businesses and tenants. The integration in the API provides full traceability, log analytics, integration in the alerts and notifications system, gets scalability and insights features and much more from the architecture in our Computing and Delivery Platforms. Our next steps are:
- Integration to the Rules Engine for the Fexco Central API services.
- Creation of the Reporting service for all areas covered by the STS.
- Enhancement of the Fraud Detection Service, creating a service more adapted to the transaction profiles mostly used by the API users.
Thanks!
[…] can find a general introduction to the compliance request to the STS in the previous post of this […]
ReplyDelete