Core Banking Integration with goAML: API, SFTP, and CSV Options

Every goAML AML reporting platform is only as good as the data that feeds it. The most sophisticated XML generation engine, the most carefully calibrated risk scoring model, and the most well-designed compliance workflow are all undermined if the underlying transaction data is incomplete, incorrectly formatted, or manually re-entered from a core banking report by a compliance analyst who misread a date field.

The integration between a bank's core banking system and its AML reporting platform is the most consequential technical decision in the entire implementation. Get it right, and the compliance function is working from accurate, complete, timely transaction data with minimal manual intervention. Get it wrong, and the compliance team spends as much time validating data quality as it does on actual compliance analysis.

The good news is that the three integration methods available — REST API, SFTP file transfer, and CSV/Excel import — cover the full spectrum of technical capability across East African financial institutions, from digital-native banks with cloud-native core banking systems to community institutions with legacy platforms and limited IT infrastructure.

---

Why Integration Matters for goAML Compliance

GIGO: Bad Data In, Bad XML Out

The goAML XSD schema is strict. Every submitted XML document is validated against the schema and against country-specific business rules. An amount stored in the core banking system as a string with thousands separator ("1,250,000") must be transformed to a decimal with exactly two places ("1250000.00"). A date stored in DD/MM/YYYY format must become YYYY-MM-DD. A transaction type stored as a numeric code ("01" for cash deposit) must map to the goAML enumeration value ("CASH_DEPOSIT").

If these transformations do not happen automatically in a well-designed integration layer, they must happen manually — and manual data preparation is the source of most goAML submission errors. Even highly skilled compliance officers make transcription errors when manually converting data between formats under time pressure.

A robust integration layer performs all transformations automatically and systematically. It enforces data quality at the point of ingestion, before the data enters the compliance workflow, while the compliance team's attention is on analysis rather than data cleaning.

Manual Re-Keying Is the Source of Most goAML Errors

In banks without automated core banking integration, the typical workflow is: IT team runs a transaction report from the core banking system and delivers it as an Excel file; compliance analyst exports the relevant data, manually maps fields to the goAML XML structure, populates a goAML template, and submits. Each manual step introduces error opportunities.

The most common errors produced by manual re-keying include: date format inversions (March 6 entered as June 3), decimal placement errors (KES 125,000 entered as KES 12,500 or KES 1,250,000), name field truncation, account number digit transposition, and currency code mismatches. Any of these errors causes the submitted XML to fail either schema validation or business rule validation at the FIU portal.

Integration Removes the Human Transcription Layer

A direct integration between the core banking system and the AML platform means transaction data flows electronically, with defined transformation rules applied programmatically and consistently. The compliance analyst never touches raw transaction data — they work with pre-validated, pre-formatted case data in a structured interface. Their time is spent on analysis and judgement, not data preparation.

---

Integration Method 1: REST API

How It Works

REST API integration enables the AML platform to request transaction data from the core banking system's API layer on a scheduled or event-triggered basis. The AML platform authenticates to the core banking API, requests transactions matching specific criteria (date range, transaction type, amount threshold), receives the response in JSON or XML format, and maps the response fields to the AML platform's internal data model.

This method supports both real-time and near-real-time data access. For STR alert generation — where a suspicious transaction pattern needs to be surfaced to a compliance officer as quickly as possible after it occurs — near-real-time API polling every 15 to 60 minutes provides the most current data.

For CTR threshold monitoring, API-based ingestion enables near-real-time per-transaction detection against the USD 15,000 equivalent threshold, so that qualifying transactions can be surfaced for CTR case creation within the Friday-of-week filing deadline.

Core Banking Systems with REST APIs in East Africa

Temenos T24 R20+ includes the T24 API Server component, which exposes TAFJ-based enquiries as RESTful endpoints. Retrieving transaction data requires an enquiry definition in T24 that specifies the fields and filter criteria, exposed through the API Server. T24 API Server supports OAuth 2.0 client credentials authentication.

Infosys Finacle 10 and 11 include the Finacle Connect API Gateway, which provides REST endpoints for account, customer, and transaction data. Finacle's API framework supports both synchronous query and asynchronous webhook notification of transaction events.

Oracle FlexCube (FCUBS 12+) provides a RESTful service layer through its Service Framework. FlexCube REST services require the appropriate service orchestration configurations and support OAuth 2.0 bearer token authentication.

Mambu is natively API-first. The Mambu Core Banking Platform exposes a comprehensive REST API with no additional configuration required. Transaction data is available through the Loans, Savings, and Current Account endpoints with extensive filtering and pagination support.

Authentication

API integration authenticates using either OAuth 2.0 client credentials flow (recommended for server-to-server integration) or API key authentication. The AML platform stores credentials in an encrypted secrets store and presents them with each request. All API communication occurs over HTTPS/TLS 1.2 or higher.

Recommended Use Cases

REST API integration is the preferred method for:

• Real-time or near-real-time STR alert generation from transaction monitoring
• Per-transaction CTR threshold detection against the USD 15,000 equivalent, with real-time currency conversion
• Customer KYC data enrichment (account opening date, declared occupation, risk classification)
• Mobile money transaction data from Daraja API or Airtel Money API

Integration Architecture Description

The AML platform's data ingestion service maintains a scheduled job that queries the core banking API on a configurable interval. The service authenticates, requests transactions since the last successful poll timestamp, maps response fields to the internal transaction model (applying date normalisation, amount formatting, code translation, and entity matching), and writes the normalised records to the transaction store. Failed API calls are retried with exponential backoff and logged with full error context for operations team visibility.

---

Integration Method 2: SFTP File Transfer

How It Works

SFTP integration uses scheduled file transfers from the core banking system to a shared SFTP server. The core banking system's batch processing (typically configured as part of the end-of-day processing run) generates a transaction extract file in a defined format — CSV, pipe-delimited, or fixed-width — and deposits it to a designated SFTP directory. The AML platform's ingestion service monitors the SFTP directory, detects new files, downloads and processes them, and moves them to an archive directory after successful processing.

This is a well-established, widely supported pattern that requires no modifications to the core banking system beyond configuring an extract report and an SFTP job. Most core banking systems deployed in East Africa have SFTP export capability in their standard installation.

File Formats Supported

CSV (comma-separated values) is the most common format for T24 and Finacle extracts. Column headers in the first row define the field mapping. The AML platform's ingestion configuration maps CSV column names to internal data model fields and applies transformation rules.

Pipe-delimited files are common in T24 COB (Close of Business) exports, particularly in older T24 installations. The pipe character (|) as a delimiter avoids ambiguity with commas that may appear in text fields like transaction descriptions.

Fixed-width files are encountered in older FlexCube installations where each field occupies a defined number of character positions. Processing fixed-width files requires a field layout specification (which character positions correspond to which field) that is documented in the core banking system's extract configuration.

Schedule and Timing

SFTP integration is inherently batch-based. The standard schedule is an end-of-day extract covering all transactions since the previous extract. For CTR threshold monitoring, end-of-day batch processing is workable but compressed: the Friday-of-week filing deadline means a Monday transaction must be detected, reviewed, approved, and submitted within four business days, and a Thursday transaction within one. End-of-day SFTP is acceptable for institutions with mature compliance workflows, but multiple intraday extracts — or a move to API-based ingestion — materially reduces the risk of missed deadlines.

For institutions requiring intraday threshold detection (to identify cash transactions at or above the USD 15,000 equivalent as soon as they post), an additional intraday extract can be configured, typically at midday. Some core banking systems support triggered extracts at configurable intraday intervals.

Most Popular Method for T24 and Finacle

SFTP extract is by far the most widely deployed integration method in East African banking. Its advantages are simplicity, universality (all core banking systems support it), zero dependency on the core banking system's API layer being available, and the mature tooling available for SFTP monitoring and processing.

Institutions that do not have immediate access to T24 API Server configuration resources, or whose Finacle Connect Gateway is not yet licensed, can implement SFTP integration with a standard report configuration and an SFTP credential — tasks achievable by most IT operations teams without specialist development resources.

Security: SFTP Protocol, Key Authentication, Encrypted Files

SFTP (SSH File Transfer Protocol) provides strong transport-layer encryption, unlike legacy FTP which transmits data in cleartext. SSH key-based authentication eliminates password-related security risks. Transaction extract files containing customer data should be additionally encrypted at rest using PGP or AES-256 encryption before depositing to the SFTP server, decrypted by the AML platform after download. This layered security ensures that even if SFTP credentials are compromised, the transaction data files are not readable without the decryption key.

---

Integration Method 3: CSV/Excel Import

Use Case

Manual CSV/Excel import is provided as a fallback integration method for institutions without the infrastructure or IT resources for automated API or SFTP integration. This is particularly relevant for smaller SACCOs, tier-3 microfinance institutions, and community banks that may not have dedicated IT operations staff.

The compliance officer (or a designated IT staff member) exports a transaction report from the core banking system, downloads it in CSV or Excel format, and uploads it to the AML platform through the import interface. The platform validates the file structure, maps columns to the data model, flags data quality issues for review, and loads the transactions into the compliance workflow.

Standard Template Format

The AML platform provides a downloadable import template in Excel format that pre-defines the required column structure, acceptable data formats for each field, and validation rules. Institutions using custom CSV exports from their core banking system use the column mapping configuration to define which column in their export corresponds to which field in the template. This mapping is configured once and saved, so subsequent imports require only the file upload step.

Data Validation on Import

The import pipeline applies the same data quality validations as the automated ingestion pipelines:

• Date format validation and normalisation
• Amount format validation (numeric, two decimal places)
• Duplicate transaction detection (transactions already in the system are flagged and skipped)
• Mandatory field presence checks
• Account number format validation
• Customer identity field checks

Validation errors are displayed in a summary report that the operator reviews before confirming the import. Records with non-critical errors can be imported with flags for manual review; records with critical errors are excluded and must be corrected in the source data and re-uploaded.

Limitations

Manual CSV/Excel import has two significant limitations compared to automated integration:

First, it is manually triggered. A compliance officer must remember to perform the import on the correct schedule. Missed imports mean gaps in the transaction data feeding threshold monitoring and risk scoring, which can result in missed CTRs.

Second, the audit trail for data origin is less complete. Automated integrations record the precise source system, export timestamp, and transfer method for every ingested record. Manual imports record only the file name, upload timestamp, and uploading user — information that may be insufficient to trace data provenance in an investigation.

For these reasons, CSV/Excel import should be treated as a transitional method while automated integration is implemented, not as a permanent integration architecture for institutions with significant reporting obligations.

---

Mobile Money Data Integration

M-PESA Daraja API

M-PESA's Daraja API (Safaricom's developer API platform) provides access to M-PESA transaction data for registered businesses. For banks with M-PESA Pay Bill or Buy Goods integrations, the Daraja C2B (Customer to Business) API delivers real-time transaction notifications as HTTP callbacks when a customer makes a payment.

For AML threshold monitoring purposes, the relevant Daraja endpoints are:

• C2B API: Receives real-time notifications of M-PESA payments to the bank's Pay Bill number
• Account Balance API: Queries current account balance for a specific Pay Bill short code
• Transaction Status API: Queries the status of a specific M-PESA transaction by its unique transaction ID

The Daraja API uses OAuth 2.0 consumer key/secret authentication. The AML platform registers as a C2B callback URL to receive real-time payment notifications, normalises the M-PESA transaction data (MSISDN, amount, transaction ID, timestamp, account reference) to the internal transaction model, and includes it in the same threshold monitoring pipeline as branch and ATM transactions.

Airtel Money API

Airtel Money's API provides similar functionality to M-PESA Daraja for banks with Airtel Money merchant integrations. The authentication model and callback pattern are comparable, with Airtel-specific field naming conventions that require mapping to the AML platform's normalised data model.

T-Kash (Telkom Kenya)

T-Kash provides developer API access for business integrations, though its market share is significantly smaller than M-PESA. Banks with T-Kash merchant accounts can integrate T-Kash transaction data through its business API layer.

Cross-Channel Monitoring for CTR and STR Detection

The critical requirement for mobile money integration is that M-PESA transactions are evaluated in the same detection pipeline as branch cash transactions, ATM withdrawals, and other cash-equivalent transactions. Each transaction is tested individually against the USD 15,000 equivalent CTR threshold; in parallel, sub-threshold activity across channels feeds the structuring-pattern surveillance that drives STR cases. Both pathways require a unified customer identity layer that links the customer's M-PESA MSISDN to their core banking customer ID and account number.

Identity matching is the technically challenging element: a customer's M-PESA account is identified by their mobile number, while their core banking account is identified by an account number and customer ID. The AML platform maintains a customer cross-reference table that maps MSISDNs to customer IDs, populated from the bank's KYC records. This cross-reference enables consistent customer resolution across all transaction channels.

---

Data Mapping — Core Banking Fields to goAML Schema

The following table shows the field mapping from Temenos T24's standard transaction extract to the goAML XML elements, including the transformation required for each field.

---

No Changes Required to Your Core Banking System

One concern that frequently arises in AML integration discussions is the question of core banking system modification. Banks are rightly cautious about any change to their core banking system — it is the most critical system in the institution, changes require extensive testing, and vendor approval may be required.

AML platform integration is designed to be entirely read-only. The AML platform queries transaction data but never writes back to the core banking system. No stored procedures, triggers, or schema changes are required in the core banking database. No agents or background processes are installed on core banking servers. The integration is a one-way data flow: from core banking to AML platform.

For API-based integration, the core banking API Server is a separate component from the core banking application itself — calling the API does not modify or risk the core banking application. For SFTP-based integration, the core banking system produces a report file as part of its existing batch processing — this is a standard reporting capability that adds negligible load.

Vendor-Neutral Approach

The AML platform's ingestion layer is designed to accommodate the specific data format and structure of any core banking system without requiring core banking vendor involvement. Integration is configured by the bank's IT team using field mapping definitions and transformation rules maintained in the AML platform's configuration — not in the core banking system.

This vendor-neutral approach means that if the bank changes core banking systems, the integration configuration is updated in the AML platform, not rebuilt from scratch. The compliance function remains operational during core banking migrations.

Implementation Timeline

Core banking integration is typically completed in 1 to 2 weeks as part of a standard 6 to 8 week AML platform implementation. The integration configuration phase requires participation from the bank's core banking IT team (to confirm field names, formats, and SFTP or API access arrangements) and is typically completed within a few days of kickoff. The remaining implementation time covers testing, data quality validation, compliance team training, and FIU portal configuration.

---

Take the Next Step

Creodata's goAML AML Reporting Platform includes a flexible data ingestion layer supporting REST API, SFTP, and CSV/Excel import for all major East African core banking systems. Our integration team has completed integrations with Temenos T24, Infosys Finacle, Oracle FlexCube, Mambu, and multiple M-PESA and Airtel Money configurations — with documented field mapping libraries for each.

Discuss your core banking integration requirements with our team: Request a Demo at creodata.com/demo