Generic Capability Context: Temenos Exchange Adapters
Introduction
This short guide describes the overall context for Temenos Exchange Adapters.
When a partner comes onto the Temenos Exchange, they can sponsor a proof of concept (PoC) in the Temenos Innovation Hub. This proves how to integrate the partner with the rest of the Temenos architecture. In general, this involves building a sample integration between the relevant Temenos products and the partner, running either on premise or as Software as a Service. Following the PoC, Temenos and the partner may choose to productise the integration as part of a join ‘Go to Market’ (GTM).
The documentation for the adapter describes the context for the integration and the architecture of the integration, following a generic pattern. The partner can either choose to:
-
Use a domain adapter with standard Temenos interfaces.
-
Jointly develop a specific adapter to run in the Temenos subscription as a ‘point of presence’.
However, a Temenos Exchange partner will always form part of a bigger system that the Temenos customer, usually a bank, has implemented using the Temenos architecture. This document describes a generic capability which provides the wider context for all Exchange adapters. This is similar to the context for a Temenos Country Model Bank (CMB), which goes further than an Exchange adapter by providing new real time, background and timer functions as well as multiple integrations.
Generic Context Diagram
The following diagram shows the generic context for a Temenos capability.
Note: Click to expand.
The context shows that the capability, even though it may be one or more Temenos products itself, still needs to integrate with other Temenos products. It also needs to integrate with:
-
Exchange partners.
-
Other bank domains, like Finance, Risk, Marketing and so on.
-
Bank partners that are not Temenos Exchange Partners.
The integration will be primarily through data and business events, though Temenos user agents (shown as API User in the above diagram) may also interact synchronously with any of these parties to the context (shown at the bottom of the above diagram).
Generic Architecture Diagram
The following diagram shows the generic architecture for a Temenos capability.
Note: Click to expand.
For each type of integration there is a service acting as a proxy for the partner or other bank domain. For instance, a proxy for a payment gateway or for document management or for a cards provider. If there is more than one partner for the same service then there will be an adapter for each partner and a set of transforms in the service for each partner, unless they are using a domain adapter, which has just one set of transforms for all partners.
Although there are multiple proxy services and multiple adapters, assuming they are deployed using the Temenos Servlite packaging, the operators of the services can choose to run them standalone or embedded in a single executable. That is, there can be one executable for all the services, and another for all the adapters. This enables the operator of the service to manage the trade-off between upgradability and complexity of operation.
SaaS Foundation
Where the capability is deployed from the catalog of the Temenos SaaS Foundation, the customer self-serving the capability will need to be asked deployment questions for each integration in the specific context diagram for the capability.
For instance, if the capability needs to send sub-ledger data to the bank’s general ledger, then, when the capability is configured, there will need to answer a question asking how to integrate to the GL. The bank can choose to use a domain adapter and do the transformations at the GL, or the bank can choose an existing adapter if one exists for, say a common GL implementation, or build a new adapter. For example, here is a context diagram for a Temenos Lending service.
Note: Click to expand.
When this service is selected by a customer from the SaaS Foundation catalog, the customer will have to configure the 11 integrations shown on the diagram.
