Ellipse Gradient for Header

Finastra Integration Guide

Integrate Finastra banking and financial-services products through FusionFabric.cloud and product-specific APIs, with Martini orchestrating secure data flows and workflows.

Finastra integration options at a glance

Finastra integrations vary by product, deployment model, and API version, but REST APIs through FusionFabric.cloud are the primary modern integration mechanism. Martini can authenticate with OAuth 2.0, consume Finastra REST endpoints, paginate through financial data, transform payloads, and expose normalized APIs for internal applications. Selected products may provide SOAP services, webhook-style callbacks, asynchronous processing, batch operations, or file-based payment and settlement processes; each must be confirmed for the target deployment. Martini can also orchestrate polling, reconciliation, file exchange, and downstream updates while keeping credentials, environment URLs, checkpoints, and error-handling rules in protected configuration.

Integration pointSupported by Finastra?Common use casesHow Martini supports it
REST APIsYesFusionFabric.cloud and many Finastra products expose REST APIs for Customers, Accounts, Transactions, Payments, Loans, and other product-specific resources.Martini can consume Finastra REST APIs, manage authenticated requests, paginate responses, transform payloads, and expose a stable internal REST API.
AuthenticationYesModern FusionFabric.cloud access generally uses application registration, OAuth 2.0, scopes, and bearer access tokens. Exact requirements vary by API product and tenant.Martini can store client credentials and token configuration in protected secrets, obtain access tokens, and apply them to workflow API calls.
SOAP APIsLimitedSelected legacy or product-specific Finastra deployments may expose SOAP or other enterprise service interfaces, but SOAP is not universal across the portfolio.Martini can consume a documented Finastra SOAP service when a supported WSDL, endpoint, and credential model are available.
Webhooks / outbound callbacksLimitedSelected Finastra products may provide callbacks or event notifications for asynchronous processing or selected business events; coverage is not uniform.Martini can receive documented Finastra callbacks through an API or workflow trigger, validate them, retrieve authoritative details, and route normalized events.
Bulk / async / batch APIsLimitedSome product APIs or operational processes may support bulk submission, asynchronous jobs, batch retrieval, or job-status queries.Martini can orchestrate submission and status polling, checkpoint long-running jobs, process item-level results, and retry transient failures when documented.
File / attachment APIsLimitedPayment files, settlement files, reports, or document exchange may be available in parts of the Finastra portfolio, but no universal attachment API was confirmed.Martini can coordinate supported file-based processes with workflows and transformations when the selected Finastra product documents the exchange mechanism.
Database / analytics accessNot confirmedDirect database or reporting access depends on the product, deployment, licensing, and vendor-support boundaries and is not the default cloud integration method.Martini can connect to approved databases when access is explicitly supported, but API-based integration is the preferred approach for managed Finastra services.

How Finastra exposes data and business events

Finastra REST APIs

REST is the primary modern integration mechanism for FusionFabric.cloud and many Finastra product APIs. Available resources, versions, filtering, pagination, and authorization depend on the selected product and deployment.

Martini implementation pattern

Martini implementation pattern: a workflow obtains an OAuth 2.0 token, calls the relevant Finastra endpoint, handles pagination or incremental filters, maps the response into a canonical model, applies business rules, and writes to downstream applications or exposes a normalized Martini API.

Implementation sequence

Register the application and obtain the required Finastra API permissions
Store credentials, token settings, and environment URLs in protected configuration
Obtain an OAuth 2.0 access token
Call the selected Finastra REST resource
Handle pagination and persist an incremental checkpoint
Validate and map the response to the target model

Finastra Webhooks and callbacks

Webhook-style notifications or callbacks may be available for selected Finastra products and business events, but support is not uniform across the portfolio. Polling may be required when no event interface is documented.

Martini implementation pattern

Martini implementation pattern: expose a secured API or workflow trigger for the documented callback, validate the request, deduplicate it, retrieve authoritative Payment or other resource details when necessary, and route the normalized event to downstream systems.

Implementation sequence

Confirm that the selected Finastra product documents the callback or event
Receive the notification through a secured Martini API or trigger
Validate authentication, schema, and correlation identifiers
Check whether the event has already been processed
Retrieve current Finastra details when the notification is not authoritative
Map and route the event to downstream systems

Finastra SOAP services

Some legacy or product-specific Finastra deployments may expose SOAP services. A WSDL, endpoint, authentication model, and supported deployment must be confirmed before using this method.

Martini implementation pattern

Martini implementation pattern: consume the documented WSDL service, construct and validate XML requests, map SOAP responses into the canonical model, and incorporate the call into a broader workflow alongside REST APIs or other systems.

Implementation sequence

Confirm the Finastra WSDL, endpoint, credentials, and supported operations
Configure the SOAP service and protected authentication settings
Construct the XML request from the workflow input
Call the Finastra SOAP operation
Parse and validate the XML response
Map the result and handle SOAP faults or retryable failures

Finastra batch and asynchronous processing

Selected Finastra products may support bulk submission, asynchronous jobs, batch retrieval, or file-based operational processes. These capabilities are product-specific and must be verified in the target API documentation.

Martini implementation pattern

Martini implementation pattern: submit a batch or asynchronous job, store its correlation and checkpoint data, poll or receive status updates within controlled limits, process successful and failed items separately, and publish reconciliation results.

Implementation sequence

Confirm the supported batch, asynchronous, or file process
Submit the request and store its job or batch identifier
Wait or poll according to documented status behavior
Retrieve completed results or item-level errors
Transform successful items and route rejected items
Persist the final processing and reconciliation outcome

Common Finastra integration patterns

Pattern 1: Synchronize Finastra Customers and Accounts

When to use this pattern

Use this pattern when customer and account information must be available in a relationship-management, servicing, or enterprise finance application. A scheduled workflow is appropriate when the selected Finastra API does not provide reliable event notifications.

Integration direction
Finastra
Martini
Salesforce
Example Mapping
Finastra FieldCanonical FieldTarget Field
customerIdcustomer.externalIdSalesforce Account or Contact external ID
accountIdfinancialAccount.externalIdSalesforce financial account reference
statusfinancialAccount.statusSalesforce account status
Martini implementation pattern

A Martini scheduler retrieves changed Customers and Accounts using the documented filter or pagination model, persists a checkpoint, maps records into a canonical structure, and upserts Salesforce data using stable identifiers. Validation failures are isolated, while transient API failures use bounded retries and are recorded for review.

Martini capabilities used
  • workflows
  • scheduling
  • API consumption
  • data mapping
  • business rules
  • error handling

Pattern 2: Publish Finastra Payment Status

When to use this pattern

Use this pattern when downstream service, finance, or customer-facing systems need accepted, rejected, pending, processed, or failed Payment status from Finastra.

Integration direction
Finastra
Martini
ServiceNow
Example Mapping
Finastra FieldCanonical FieldTarget Field
paymentIdpayment.externalIdServiceNow correlation reference
statuspayment.statusServiceNow task state
failureReasonpayment.exceptionReasonServiceNow work notes
Martini implementation pattern

Where a documented callback exists, Martini receives and validates it; otherwise, a scheduled workflow polls Payment status. Martini retrieves authoritative details when necessary, deduplicates by payment identifier, maps status values, and creates or updates a ServiceNow task only for actionable failures.

Martini capabilities used
  • API exposure
  • workflow triggers
  • API consumption
  • data mapping
  • idempotency rules
  • error handling

Pattern 3: Synchronize Lending Data

When to use this pattern

Use this pattern when a lending product must share Loans, Customers, and Collateral with a servicing, risk, reporting, or customer-management application.

Integration direction
Finastra
Martini
Microsoft Dynamics 365
Example Mapping
Finastra FieldCanonical FieldTarget Field
loanIdloan.externalIdMicrosoft Dynamics 365 loan reference
outstandingBalanceloan.balanceMicrosoft Dynamics 365 balance
collateralIdcollateral.externalIdMicrosoft Dynamics 365 collateral reference
Martini implementation pattern

Martini retrieves lending resources, validates relationships between Loans and Collateral, normalizes dates and monetary values, and applies ownership rules before updating the target. Incomplete records are routed to an exception path, while transient failures are retried without duplicating successful updates.

Martini capabilities used
  • workflows
  • API consumption
  • data mapping
  • validation
  • business rules
  • retry handling

Pattern 4: Reconcile Finastra Transactions

When to use this pattern

Use this pattern when Transactions or payment results must be compared with postings in an ERP or finance platform to identify missing, duplicated, or mismatched items.

Integration direction
Finastra
Martini
SAP S/4HANA
Example Mapping
Finastra FieldCanonical FieldTarget Field
transactionIdtransaction.externalReferenceSAP S/4HANA document reference
amounttransaction.amountSAP S/4HANA document amount
valueDatetransaction.valueDateSAP S/4HANA posting or value date
Martini implementation pattern

A scheduled Martini workflow retrieves Transactions incrementally, preserves currency and precision, compares stable references and amounts with SAP S/4HANA, and posts only approved unmatched items. Duplicate, late, or inconsistent results are written to an exception queue or operational case process rather than silently corrected.

Martini capabilities used
  • scheduling
  • API orchestration
  • data mapping
  • reconciliation rules
  • checkpointing
  • error handling

Applications commonly integrated with Finastra

Finastra products commonly participate in broader financial-services architectures. The exact integration direction depends on the Finastra product, system of record, API availability, and ownership of each business object.

Application Scenario Direction Martini Pattern
Salesforce Synchronize Customers, Accounts, payment status, and lending information with relationship-management and service processes. Finastra → Martini → Salesforce A scheduled or event-triggered Martini workflow retrieves changed Finastra objects, maps identifiers and financial attributes to Salesforce, applies ownership and validation rules, and performs idempotent upserts. Failures are logged for operational review.
SAP S/4HANA Reconcile Payments, Transactions, settlements, customer data, and financial postings with enterprise finance processes. Finastra → Martini → SAP S/4HANA Martini retrieves Finastra payment or transaction data, normalizes dates, currencies, references, and debit-credit values, then posts approved data to SAP S/4HANA. Reconciliation exceptions are routed separately from technical retries.
Oracle NetSuite Transfer payment, transaction, customer, and reconciliation information into finance operations. Finastra → Martini → Oracle NetSuite A Martini workflow consumes Finastra API responses, transforms them into NetSuite-compatible financial structures, checks source identifiers for duplicates, and records item-level errors for reprocessing.
Microsoft Dynamics 365 Coordinate Customers, Accounts, lending information, and Payment status with customer-service and business-process applications. Finastra → Martini → Microsoft Dynamics 365 Martini exposes or consumes APIs on both sides, uses a canonical customer and account model, applies source-of-truth rules, and routes conflicting updates for review rather than overwriting them automatically.
ServiceNow Create cases, incidents, or operational tasks for payment failures, reconciliation breaks, and integration exceptions. Finastra → Martini → ServiceNow Martini detects failed or unmatched Finastra processing, enriches the exception with correlation and transaction details, and creates a ServiceNow task while preventing duplicate case creation.
Jira Create technical work items for recurring API failures, reconciliation issues, and deployment defects. Finastra → Martini → Jira A Martini error-handling workflow classifies persistent failures, suppresses duplicate alerts using a correlation key, and creates Jira issues with sanitized diagnostics and links to operational records.
Microsoft Power BI Publish curated financial, payment, account, and operational data for reporting and monitoring. Finastra → Martini → Microsoft Power BI Martini extracts approved Finastra data, applies reporting transformations and privacy rules, and writes it to an approved reporting or ingestion layer used by Power BI.

How to build a Finastra integration in Martini

Objective

Identify the exact Finastra product, environment, API version, tenant, and authentication requirements before building the workflow.

Instructions in Martini

  • Confirm whether the integration uses FusionFabric.cloud, a product-specific REST API, SOAP service, callback, or file process
  • Register the application and obtain required OAuth 2.0 scopes or other documented credentials
  • Store client secrets, token URLs, scopes, and environment-specific values in Martini protected configuration

Objective

Select the trigger that matches the vendor capability and business timing requirements.

Instructions in Martini

  • Use a Martini API or documented Finastra callback when event-driven processing is available
  • Use a scheduler for polling, reconciliation, or incremental synchronization
  • Use a controlled batch trigger for documented asynchronous or file-based processes

Objective

Call the selected Finastra interface and obtain complete, authoritative data for processing.

Instructions in Martini

  • Obtain an access token and call the relevant Finastra endpoint
  • Handle pagination, cursors, continuation tokens, or job status according to the API contract
  • Retrieve authoritative resource details when a callback contains only a notification

Objective

Coordinate vendor calls, target-system calls, checkpoints, validation, and business decisions in a maintainable Martini workflow.

Instructions in Martini

  • Separate technical transport steps from business validation and routing
  • Persist correlation identifiers and incremental checkpoints where durable state is required
  • Branch successful, rejected, duplicate, and retryable outcomes explicitly

Objective

Convert Finastra’s product-specific payloads into a canonical model and target-system structures.

Instructions in Martini

  • Map Customers, Accounts, Transactions, Payments, Loans, or Collateral using explicit field rules
  • Preserve currency precision, signs, identifiers, statuses, and date semantics
  • Transform JSON or XML payloads and isolate version-sensitive mappings from business logic

Objective

Protect financial data integrity and apply source-of-truth, idempotency, and reconciliation rules before writing data.

Instructions in Martini

  • Validate required identifiers, relationships, monetary values, and status transitions
  • Use stable vendor identifiers or documented idempotency keys to prevent duplicate writes
  • Route incomplete, rejected, or conflicting data to an exception path

Common Finastra data objects used in integrations

ObjectTypical UseCommon target systemsMartini handling
CustomerRepresents a person, business, or other banking customer used in customer servicing, account ownership, lending, and relationship processes.Salesforce, Microsoft Dynamics 365, SAP S/4HANA, Oracle NetSuiteMartini retrieves and validates customer identifiers, maps names and contact data to a canonical model, applies source-of-truth rules, and performs idempotent updates.
AccountRepresents a deposit, current, savings, or other financial account associated with a customer or institution.Salesforce, Microsoft Dynamics 365, SAP S/4HANA, reporting platformsMartini maps account identifiers, ownership, status, balances, and dates according to the selected API contract while protecting sensitive values in logs.
TransactionRepresents a financial movement associated with an account or payment process and supports reconciliation and reporting.SAP S/4HANA, Oracle NetSuite, Microsoft Power BI, reconciliation storesMartini uses stable transaction references, preserves currency and precision, handles pagination and incremental filters, and prevents duplicate downstream postings.
PaymentRepresents a payment instruction or payment transaction with status and settlement information.SAP S/4HANA, Oracle NetSuite, Salesforce, ServiceNowMartini validates payment status and references, consumes callbacks where available or polls otherwise, separates business rejection from technical failure, and routes exceptions.
LoanRepresents a lending agreement with borrower, balance, terms, and repayment information.Salesforce, Microsoft Dynamics 365, risk and servicing applications, reporting storesMartini normalizes dates, amounts, identifiers, and status values, validates required lending fields, and publishes a stable API or synchronized downstream representation.
CollateralRepresents assets or guarantees associated with a lending arrangement.Risk applications, servicing platforms, Microsoft Dynamics 365, reporting storesMartini links Collateral to Loans using source identifiers, validates valuation and relationship data, and routes incomplete or inconsistent records for review.

Authentication and security considerations

OAuth 2.0 and application access

Modern FusionFabric.cloud access generally uses application registration, OAuth 2.0 scopes, and bearer access tokens. Exact grants, consent requirements, token endpoints, and provisioning vary by Finastra API product and tenant.

Protected configuration

Store client credentials, token settings, environment URLs, scopes, and certificates in Martini secrets or protected configuration. Use separate credentials for development, testing, and production.

Product-specific controls

Legacy or customer-managed Finastra interfaces may use basic authentication, mutual TLS, API gateway credentials, or enterprise identity federation. Confirm the selected product’s security requirements before implementation.

Financial data protection

  • Restrict access to Martini APIs and workflows using authentication and authorization policies.
  • Minimize payload logging and mask account, customer, and payment identifiers.
  • Protect data in transit and at rest and align retention and residency controls with institutional requirements.

Operational considerations for Finastra integrations

Pagination and incremental retrieval

Customers, Accounts, Transactions, and Payments may require cursors, offsets, page tokens, or continuation mechanisms. Use the Finastra-supported model and persist checkpoints for restartable workflows.

Rate limits and retries

Quotas vary by API, tenant, subscription, and environment. Limit concurrency, respect Retry-After when provided, use bounded exponential backoff, and distinguish transient HTTP failures from business validation errors.

Idempotency and integrity

Use stable vendor identifiers, correlation IDs, or documented idempotency keys. Preserve currency precision, debit and credit signs, value dates, booking dates, time zones, statuses, and settlement references.

Errors and reconciliation

Separate authentication failures, throttling, invalid instructions, duplicates, and partial batch failures. Record item-level outcomes where available and route unresolved mismatches to operational review.

Change management

Monitor API versions, OpenAPI definitions, deprecations, required fields, and enum changes. Test mappings against each target Finastra environment before promotion.

Why use Martini instead of scripts or point-to-point integrations?

Coordinate product-specific interfaces

Finastra is a portfolio of products rather than one universal API contract. Martini provides a workflow layer that can coordinate REST APIs, selected SOAP services, callbacks, files, databases, and downstream applications without embedding all logic in point-to-point scripts.

Centralize transformation and rules

Martini maps Customers, Accounts, Transactions, Payments, Loans, and Collateral into target models while keeping validation, source-of-truth, reconciliation, and idempotency rules explicit and reusable.

Improve operational resilience

Workflows can manage pagination, checkpoints, retries, exception routing, monitoring, and controlled asynchronous processing. This makes financial data flows easier to troubleshoot and maintain as API versions or deployment models change.

Expose stable internal APIs

Martini can expose a normalized REST API so internal applications do not need to depend directly on Finastra-specific authentication, endpoints, schemas, or version changes.

Frequently asked questions

How can Finastra be integrated with enterprise systems?

Finastra can be integrated through FusionFabric.cloud and product-specific REST APIs, with OAuth 2.0 commonly used for modern API access. Depending on the product and deployment, integrations may also use selected SOAP services, callbacks, asynchronous processing, batch operations, or file-based financial processes. The exact product API and environment should be confirmed first.

Can Martini integrate with Finastra?

Yes. Martini can consume documented Finastra REST APIs, authenticate using the required OAuth 2.0 or product-specific method, orchestrate workflows, map financial data, and expose normalized APIs. It can also consume selected SOAP services and receive documented callbacks where the Finastra product supports them.

Do I need a connector to integrate Finastra with Martini?

No. A dedicated Finastra connector is not required. Martini can integrate using Finastra’s confirmed native mechanisms, including REST APIs, OAuth 2.0, selected SOAP services, documented callbacks, and supported batch or file processes.

Is there any extra Lonti cost to integrate Finastra with Martini?

Lonti does not charge an additional per-connector or per-vendor fee to integrate Finastra. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from Finastra, cloud infrastructure, or other third-party systems based on subscription, usage, licensing, and deployment model.

Which Finastra integration methods should architects use first?

REST APIs through FusionFabric.cloud or the relevant product API are the preferred starting point for modern integrations. OAuth 2.0 is the expected authentication model for many current APIs. SOAP, callbacks, asynchronous jobs, batch processes, and files should be considered only when documented for the selected Finastra product and deployment.

Can Martini receive Finastra events or payment callbacks?

Only selected Finastra products and APIs may provide webhook-style notifications, callbacks, or event notifications. Martini can receive and validate a documented callback through an API or workflow trigger. When no event interface exists, scheduled polling or a documented asynchronous-status process can be used instead.

How does Martini synchronize Finastra data reliably?

Martini can use vendor-supported modified-date filters, cursors, sequences, event notifications, or business dates for incremental synchronization. Workflows can handle pagination, persist checkpoints, map product-specific objects, apply idempotency rules, and reconcile late, duplicate, or mismatched Transactions and Payments.

Can Martini expose an API façade for Finastra?

Yes. Martini can expose a REST API that presents a stable internal contract while hiding product-specific Finastra endpoints, authentication details, and schema variations. The façade can validate requests, orchestrate Finastra calls, transform responses, apply authorization rules, and provide consistent error handling.

Related Martini documentation

API Integration

Workflows

Data Processing

Security Operations

Integrate Finastra with Martini

Build secure, maintainable Finastra integrations using product-specific APIs, workflows, transformations, and operational controls in Martini.

EXPLORE MARTINI
BOOK A DEMO