SIGTB FinTech is constituted in a Technological Platform of Cloud Computing Services oriented to the design, development and deployment of Bank Cores for any organization, based on an open and new generation architecture designed to accelerate business processes and cycles of a Financial Entity

The FRAMEWORK environment is the set of facilities provided by the Platform that allows modeling the accelerated construction strategy of Business Processes, Services and Sectorial Verticals

From the different WORKSHOPS provided by the FRAMEWORK SIGTB it will be possible to customize the integral behavior of the Financial Institution: from the corporate style, the conformation of the offer, to the modeling of all its business processes...

Customization Model

It´s composed by:

• Transactional Core Layer,
• Data odel Transaction Layer,
• SDK API Layer,
• Workshops & Engines Layer  ( for TX & Batch respectively ).

One of the main characteristics is that it offers the possibility of modeling and building generic parts, encapsulating independent and reusable models. 

The Transactional Core is made up of the following Modules:

1. People Management: Manages the administration of all those Natural and Legal Persons and the relationship with the Financial Institution, whatever their role (client, supplier, employee, etc.) and relationship situation (Prospect, Pre-Client, Active Client , Partner, etc)
2. Management of the Product Catalog: It allows the definition, creation, modification and maintenance of all the products and services sold or to be commercialized in the Financial Institution, allowing to manage in a customizable and granular way of all their attributes with maximum depth of parameterization. Minimizes the time required to create new products, through the reuse of previously existing "objects". This approach limits computer development only to creating new objects. These new objects also have a very limited functional scope so they can be rapidly developed and tested. In terms of measuring the time required to define a new product, the weighted average is estimated to be around 8 hours. It encapsulates the maximum of business logic in these objects, so that the same logic is executed independently of the user interfaces used and, therefore, of the channel used. It is not only about the definition of the product as a set of conditions, but through the relationships and the possibilities of incorporation of information, the treatment of the products by the user of the entity is facilitated. For example: it allows associating commercial information related to products and services (Sales Argument, Related Products: complementary and substitutes, Information about the Competition).
3. Accounting Management: It allows the definition and administration of all the accounting, financial and budgetary exploitation sub-products. It allows the creation of the chart of accounts and the accounting record of the different transactions of the Entity. This module is based on the parameterization and flexibility to adjust to the changes that may occur in the future, minimizing the impact on the rest of the applications on which the strategy of a Financial Institution is based, and that apply added value to the business. .
4. Agreement Management: It allows managing the negotiation and contracting policies of the Financial Institution and any of the contractual and operational links with third parties. All operational, regulatory and state management operations are based on this Core Module.
5. M.C. Management of Accounting Movements: Manages the customizable composition of the accounting imputation structures, so that the management of the operational movement is carried out from automatic events that do not imply any type of manual management and also minimize or neutralize which -any type of future impact due to modification of accounting regulations.
6. A.S. Management of Notes and Balances: Manages the customizable composition of the structures of operational annotations and the allocation in the different types of balance. This Module has been conceived so that all the management is absolutely parameterizable and also, to guarantee that given a movement, any type of multiple entry or multiple imputation in different balances is managed in a single automatic and transparent point.
7. OUT OF. Electronic Journal Management: Manages the traceability and ON LINE auditing of all movements, whether they are operative movements or consultative movements. Likewise, from this Module all the Treatments of Retrocessions, Cancellations or Immediate Incidents can be operated.
8. G.I. Incident Management: Manage any type of incident that may occur in the activity of the Financial Institution. It manages both the ON LINE incidents, as well as those that could be generated in the OFF LINE activity (typical situation in Batch scheme). The Module is able to discern in which of these situations it can act automatically, generating a resolution event and when it must generate a queue of requirements so that the incident is derived for human treatment.
9. E.C.U. Management of Entities, Centers and Users: This is a CROSS type Module that acts in all segments of the Application and manages the management of Entities, Centers, Users, Profiles and Attributions. This parameterizable and customizable management allows the adaptability of the Application to the different organizational structures of any Financial Institution.
10. Coexistence Management: This Module manages communication between Organizations via interfaces, ETLs, APIs, Web Services or any other element that allows the exchange and management of information between third Organizations and the Financial Institution after guaranteeing absolute interoperability.
11. User Interface Management: Provides all User interfaces (screen users) that allow the End User or System Operator to interact from the front with any of the Modules described, regardless of the functional layer in the one they reside. In other words, it is all the application "screens" through which any user works and unfolds.

The Data Model Abstraction Layer delivers publications of internal APIs that will be consumed as interstitial services between the different CORE Modules

The main advantages provided by this Model:

1. Decoupling of the Data Model: If any type of modification to the Model occurs, the CORE will not suffer any structural trauma. The Applications will continue to function transparently to the Database Manager, it will only be necessary to update the API service that corresponds to the modification.
2. Database Engine Independence: It means that CORE will be able to support a Database Engine change without the need to resort to syntax modification or recompilations.
3. Clean Code: Offers a Catalog of APIs to manage interactions with the Database. In this way it is possible, on the one hand, to decouple the Inquire layer and on the other hand, to obtain a clean Code of the presence of SQL predicate.

Application Modeling Environment and Business Operations

The Platform provides an operational environment for the development and integration of applications that allows to manage Catalogs, drastically shortening the Development Process cycles.

It proposes to manage the development from the perspective of autonomous, integrable, encapsulated and reusable components, whether it is pieces of code, as well as APIs that manage the interaction with the I-O layer (DDBB - Data Model). It presents a Comprehensive Model that allows managing the End-to-end Application Development and Publication Process, providing coverage to each and every one of the phases that comprise it.

Development strategy

The development strategy focuses on strongly shortening the effort cycles based on the Componentization Philosophy, which:

• Allows integrating elements from different types of environments or technologies,
• Reuse of elements
• Adaptation of idiomatic and normative turns or "Tropicalization of applications".

SIGTB Workshops & Engines Environment allows defining, parameterizing and modeling the Business Transactions of any Organization

It is supported by a WorkFlow Manager that allows any Business Analyst to capitalize on their know-how about the Operations they manage, becoming the architect of the Transaction itself, without the need to resort to IT experts.

At the time of definition, the Analysts parameterize the Transactions using the WORKSHOPS tools.

Then, at runtime (all this happens in the Back End and is totally transparent to the front end operation), the ENGINES identify the flow to go through, interpreting the diagramming expressed in the WORKSHOPS.

Immediately after this, it identifies the Transaction to be executed according to the analysis of conditions that arise from the operation that is happening in front.

With the information obtained from different entities ...

• inspecting the corresponding Agreement,
• inspecting the composition of the treated Product in the Catalog,
• inspecting the situation of the Client in People
• And also, with all the information collected in the environment that is being acted on from the front,

The ENGINES have the ability to interpret and execute the TRANSACTION automatically, solving:

• the business operation,
• the accounting imputation,
• the movement of all notes and balances
• updating the corresponding entry in the Electronic Journal

SIGTB Batch Workshops Environment allows defining, parameterizing and modeling the Deferred Processes of a Financial Institution

Banks operate 7x24, and traditional solutions offer backoffice systems that operate deferred. This circumstance means that the system, at night, stops the online processes, and that many client operations are not reflected until after the execution of the batch.

The lack of synchronization between online processes and the back office that most transactional systems designed with traditional architectures present means that to solve this type of process requires highly sophisticated architectures - therefore, very high cost in terms of development efforts. and later, very complex maintenance-.

Due to the fact that the SIGTB Platform is natively distributed, it allows to reduce to a minimum the deferred processes - night executions - since it admits to keep the backoffice and online operations synchronized without structural traumas in performance, which is why it ensures completeness and The veracity of the information, and therefore, the integration with different channels, bankonline, ATH's, etc., does not represent inconveniences for the system.

In this way, by integrating computing, storage, software and services capabilities, it allows the management of a system that achieves the maximum optimization of resources and guarantees the scalability of any business. This is summarized in the following advantages: (a) 24x7 operation. (b) Execution of batch processes in parallel (c) Reduction of global execution times of batch processes (d) Integrity that ensures the completeness of the information (e) Reduction of infrastructure costs to support batch processes.

SIGTB incorporates the concept of SLIM BATCH, in this way it is possible to manage, whatever the number of possible operations (which were conventionally derived from massive batch processing) in an atomic way, activating a background instance from ON LINE itself.

This facility offers the possibility of reducing the number of operations consumed in a traditional Batch environment to the minimum possible expression, allowing:

1. Plan Processes
2. Assign Sequence Order
3. Configure Parallel Executions (Map Reduce)
4. Determine the Execution in the chosen modality (background or Typical Batch).

On the other hand, the BATCH ENGINE allows to start Processes configured in BATCH WORKSHOP. All the Processes that invoke TX will do so through queues and the invoked transactions will be resolved by reusing TX ENGINE.

Depending on how the execution has been configured, the Process will be executed in atomic form in the ON LINE or the Batch will be processed in Batch.

If the chosen execution is background, then a virtual channel will be proposed so that the execution does not disturb the performance of the ON LINE operation

OBJECTIVE: To stimulate the participation of the user sectors in the Final Solution Modeling

Prototype-Oriented Development: Building / Customization Model

OBJECTIVE: Training of users and future trainers

This process has been designed to cover the training of the different types of users that can interact with the Solution and also prepare future trainers identified by the Client Organization.