Skip to content
AMTEXConsulting

Case study · Financial Services

Bank connectivity for a multi-entity Fusion Financials estate

How we replace hand-run bank file exchanges with monitored, versioned Oracle Integration Cloud integrations across payments, statements and reconciliation. Written as the reference engagement we deliver, not as a single client's account.

Client
Reference architecture
Industry
Financial Services
Solutions
Oracle ERPOracle IntegrationOracle OCI
Technology
Oracle Integration CloudSFTP & File IntegrationOCI Vault & IAMOCI Object StorageOracle Fusion Cloud ERP

Challenge

The pattern repeats across finance organisations on Fusion: several legal entities, several banks, and payment and statement files exchanged through scripts the treasury team runs by hand. Nobody is alerted when an exchange fails, so a missing statement is discovered at reconciliation. Credentials sit in the scripts, which is usually how the audit finding starts.

The treasury team wants to stop being the integration layer. Internal audit wants credentials out of files and a record of every exchange. Finance wants to know, the same day, when a payment file did not reach the bank.

Context

This is a reference engagement: the architecture, build order and operating model we bring to bank connectivity work. A typical delivery runs as a fixed-scope discovery followed by a build that goes bank by bank, starting with the one that carries the most payment value.

Architecture

Solution architecture
  1. Oracle Fusion ERP

    • Payables
    • Cash Management
  2. Integration

    Oracle Integration Cloud

    Scheduled · PGP · Tracking

  3. OCI

    • Vault
    • Object Storage
    • Monitoring
  4. Banks

    • Bank A (SFTP)
    • Bank B (API)
    • Bank C (SFTP)

Solution

We define canonical payment and statement models in OIC once, then write one map per bank format. Fusion produces payment files through its payment process profiles; OIC picks them up, transforms, encrypts with PGP using keys held in OCI Vault, delivers over SFTP or the bank's API, and archives the exact bytes sent to Object Storage with the Fusion payment reference as metadata. Statements travel the other way into Cash Management for automatic reconciliation.

  • Business identifiers (payment batch, legal entity, bank account) are set as tracking variables so every alert names the record, not the integration.
  • Technical faults route to integration support; business exceptions (rejected batch, unknown account) route to treasury with the fix.
  • Every integration lives in source control and is promoted through environments by pipeline, with connection values injected per environment.
  • A daily exchange summary tells treasury what was sent, what was received and what is outstanding, before anyone asks.

Business impact

What changes for the organisation: the treasury team stops running scripts, failures surface within minutes to the people who can act, credential handling closes the audit finding, and every file ever exchanged can be produced on request. The integrations become a product with an owner, a version and a monitor, which is the only state in which money movement should run.

Because this page describes the reference engagement rather than one client, it carries no client figures. Results for a specific estate are shared under NDA.

Key takeaways

  1. 01Treat bank integrations as products with owners, monitoring and versions.
  2. 02Put credentials in a vault before the auditor asks.
  3. 03Alert the business, not just IT, when money movement fails.

Facing something similar?

We will walk you through how we approached this one and what would be different for you.