Architecture Overview

Fintegrator TODS is a data flow engine for Temenos Transact (T24), built on the Morph Flow processing core. Morph reflects the morphosis of data — the transformation of Transact XML and JSON structures into normalised, relational SQL. The bi-directional nature comes from the ability to drive bulk updates back into Transact through OFS (Open Financial Services) messages, closing the loop between the operational data store and the core banking system.

Architecture goals

  • Deliver business-ready data from Transact (T24) in seconds, not overnight batches.
  • Separate control-plane operations from data processing for predictable runtime behavior.
  • Support controlled, repeatable deployment and upgrades in Kubernetes environments.
  • Provide auditability, observability, and reconciliation patterns expected in regulated banking environments.

Functional layers

1. Experience layer

  • Browser-based operational console for configuration, mappings, and runtime controls.
  • Designed for operations and data teams that need fast visibility and safe actions.

2. API and orchestration layer

  • Unified service interface used by both UI and automation.
  • Centralizes control functions such as mappings, replication controls, configuration, and health checks.

3. Processing layer

  • Handles asynchronous workloads, scheduling, and OFS interaction flows.
  • Isolates long-running processing from interactive user activity.
  • Executes mapping and transformation logic that turns source records into analytics-ready relational structures.

4. Data layer

  • Stores transformed, SQL-accessible structures for downstream BI and reporting tools.
  • Supports curated views and consumer-ready query access patterns.

Integration patterns

Fintegrator TODS supports two proven ingestion patterns:

  • Direct change-driven replication flow (simpler operational model).
  • CDC/event-driven flow with Debezium (for organizations standardizing on that pattern).

Both patterns converge into the same transformation and SQL delivery model, so client outcomes remain consistent.

End-to-end flow (conceptual)

Changes from Transact (T24)
  -> ingestion and control orchestration
  -> transformation and mapping pipeline
  -> SQL-ready target structures
  -> reporting, analytics, and operational use cases

Deployment model

Fintegrator TODS is delivered as containerized services with Helm-based deployment to Kubernetes. The deployment model provides:

  • Environment-specific values and secrets.
  • Repeatable install and upgrade procedures.
  • Independent scaling and restart behavior by service role.
  • Clear separation between customer-specific configuration and product defaults.

Architectural options

Option A: Without Debezium

Recommended for organizations prioritizing lower operational complexity and a direct integration path.

Architecture Option A (Without Debezium)

Option B: With Debezium

Recommended for organizations with existing CDC/event platform standards and integration governance based on Debezium.

Architecture Option B (With Debezium)

Data flow reference

Fintegrator TODS Data Flow

Security and operational posture

Fintegrator TODS is built for production operation in banking contexts:

  • Configuration and secrets are environment-scoped.
  • Runtime actions are exposed through controlled APIs and governed UI workflows.
  • Health and readiness endpoints support platform monitoring and automation.
  • Runtime telemetry enables traceability for operations and incident analysis.
  • Service units are independently restartable and scalable.

Business outcomes

For client organizations, the architecture delivers:

  • Faster access to Transact (T24) data in SQL form for reporting and analytics.
  • Reduced integration and operational overhead versus custom point-to-point implementations.
  • Consistent deployment process across test, staging, and production environments.
  • A scalable path that supports both direct and CDC-based enterprise integration strategies.