PaymentOps documentation

Overview

PaymentOps is a vendor-neutral operational control plane for payments. It sits above a bank's existing payment engines, SWIFT infrastructure, screening systems, ledgers, reconciliation systems and case-management tools, and answers three questions for every payment: what happened to it, why it needs human intervention, and what should happen next.

PaymentOps builds one canonical record of each payment by correlating events and records from systems that otherwise each see only part of the lifecycle. On top of that record it provides:

• universal payment search and an end-to-end timeline for every payment;
• exception queues, investigation management and automatic evidence gathering;
• configurable runbooks with recommended remediation;
• controlled payment-related actions with maker/checker approval;
• SWIFT Exceptions and Investigations handling;
• incident detection, SLA management and notifications;
• operational analytics and audit evidence;
• AI-assisted explanation and drafting, always tied to evidence.

What PaymentOps does not do

PaymentOps never processes money. It does not hold funds, keep balances or execute settlement, and it is not a system of record for either. Any action that affects an underlying payment is carried out by the authoritative system through a controlled integration. Existing systems continue to move money; PaymentOps is where people and automation understand and operate the payment lifecycle.

It is also not a payment hub, a bank ledger, a sanctions-screening engine, a fraud engine, a replacement for SWIFT connectivity, an accounting platform, a general-purpose workflow platform or a universal reconciliation platform.

Principles

• Read first. PaymentOps delivers substantial value in read-only mode. A bank can deploy it without granting write access to payment systems.
• Deterministic facts before AI. Payment state is calculated from structured events, explicit rules and authoritative sources. Language models explain and draft; they do not decide.
• Evidence is preserved. Source data is never overwritten. Raw, normalized and derived data stay distinguishable.
• Human control for material actions. Permissions, maker/checker controls, approval thresholds, configurable automation policies and complete audit histories apply.
• Vendor neutrality. The canonical model does not depend on any specific payment-hub, messaging or ledger vendor. Vendor formats are translated into it.
• Everything is explainable. Every recommendation, derived state and automated decision refers to the events and rules behind it.

Core concepts

Canonical payment

A canonical payment is a record of a payment that is independent of the systems that process it. It holds the payment identifiers (payment ID, UETR, instruction IDs, end-to-end ID and transaction IDs), the parties (debtor, debtor agent, creditor, creditor agent and any intermediary agents), the instructed and settlement amounts, currency and value date, the payment type, service level and clearing channel, and the current operational and processing state. It links to the payment's messages, events, ledger entries, screening events, cases, actions, incidents and attachments.

The UETR (unique end-to-end transaction reference) is the identifier SWIFT assigns to a payment so that it can be followed across every institution that handles it.

Correlation

Correlation is the process of deciding that records from different systems belong to the same payment. PaymentOps correlates on combinations of UETR, message ID, instruction ID, end-to-end ID, transaction ID, internal payment IDs, source-system references, case identifiers, account, amount, currency, value date, BIC and message relationships.

• Deterministic identifiers are used first. Every correlation that is not deterministic carries a confidence score, and the evidence behind the score is shown, for example an exact UETR match, an exact amount and currency, an exact value date and an exact account.
• Authorized users can join records that were wrongly separated and detach records that were wrongly linked. A justification is recorded and the correction is audited.
• Every normalized property keeps its provenance: the source system, source record ID, ingestion timestamp, original field and the transformation applied.

Data layers

PaymentOps keeps four layers apart and lets users see which one they are looking at: the raw source payload (retained according to the customer's retention policy), the parsed representation, the normalized event and the derived payment state. Derived information never overwrites the original record.

Events

Every observation about a payment is stored as an append-only event with an event type, event time, ingestion time, payment ID, source system and reference, the original payload, normalized attributes, the correlation method and confidence, and a schema version. Ingestion is durable and processing is idempotent: if the same SWIFT message arrives twice, no duplicate event is created.

State engine

The state engine derives an operational state for each payment independently of any single source system. States are:

Stage	States
Before release	Received, validating, held, screening, ready to release
In flight	Released, network accepted, counterparty accepted, settling
Completed	Settled, credited
Unsuccessful or reversed	Rejected, returned, cancel requested, cancelled
Needs attention	Under investigation, stalled, unknown

Every derived state shows its supporting evidence: the event it came from, the timestamp of that event and the rule that produced the conclusion. For example, a payment is network accepted because a SWIFT ACK was received at a stated time, under a named rule.

Freshness and completeness

Every data domain on screen shows how current it is, for example SWIFT events, payment hub, nostro ledger and sanctions, each with its own time or an unavailable indicator. When a connector is unavailable, the payment states that its evidence may be incomplete. PaymentOps never implies a complete payment state when a required source is stale.

Finding and understanding a payment

Universal search

Users search across all connected systems from one box. Searchable fields are UETR, payment ID, transaction ID, instruction ID, end-to-end ID, debtor name, creditor name, account, IBAN, BIC, amount, currency, date and time, case ID and customer reference.

• Filters combine. For example: currency is USD, amount above 1,000,000, creditor agent CITIUS33, state stalled, in the last four hours.
• Results for indexed transactions normally appear within two seconds.
• Search respects row-level, field-level and tenant-level authorization, so users only find what they are permitted to see.
• Users can save searches, configure columns and share deep links to any result.

Payment detail

The payment detail screen is the primary screen of the product. It contains:

• Header: amount, currency, debtor, creditor, source, destination, UETR, current state and risk and SLA indicators.
• Timeline: every event in order, each labelled with the system it came from.
• Messages: each message can be viewed in a business-friendly form, as structured fields or as raw XML or MT. Two messages can be compared side by side, and XML is highlighted.
• Relationships: the original instruction, the outbound instruction, responses, returns, cancellations, investigations and accounting entries.
• Actions: the actions the user is permitted to take, shown in context.

Why this state

Every conclusion answers five questions: what do we think happened, why, which evidence supports it, which rule or runbook produced the conclusion, and what action is recommended. Evidence is presented as a checklist of what was found and what was not, for example a SWIFT ACK, a pacs.002 with status ACSP and a nostro debit found, and a beneficiary credit confirmation and a return not found. The recommended action follows from that result, together with the runbook and branch that produced it.

Exceptions and the operations queue

An exception is an individual payment that needs attention. PaymentOps detects three kinds:

• Explicit exceptions are raised by underlying systems: a rejected payment, a sanctions hold, a validation error or a SWIFT NAK.
• Derived exceptions are calculated from events, for example a pacs.008 that was transmitted and has no acknowledgement within 60 seconds.
• Statistical exceptions are detected from abnormal behaviour, for example a correspondent whose 95th percentile response time moves well above its normal level, which signals operational degradation.

The operations queue

Users receive one consolidated queue. Each item shows priority, exception type, age, value and time left on its SLA, and can be filtered by assigned user, assigned team, customer segment, correspondent, payment rail and status.

• Items are assigned to an individual or a team, and can be claimed and released.
• Bulk actions, saved filters and role-specific queues are supported.

Investigations and cases

A case is an operational investigation into one payment. A case holds its ID, type, related payment, external case reference, originating institution, current owner, status, priority, SLA, evidence, messages, activities, proposed resolution and final resolution.

Cases move through new, triaged, in progress, waiting external, resolved and closed. A case can be reopened.

Automatic evidence gathering

When a case is created, PaymentOps gathers the relevant evidence without the operator searching each system. For a claim of non-receipt it identifies the UETR, finds the original payment and retrieves the payment-hub events, screening events, network evidence, counterparty statuses and ledger and nostro evidence. It then checks for returns and for existing investigations, and assembles a case evidence package.

Runbooks

A runbook is a documented operating procedure that PaymentOps executes step by step. Each runbook defines the case type that triggers it, the evidence it requires, the sequence of checks, branching logic, permitted actions, escalation paths and whether it is eligible for automation.

A claim-of-non-receipt runbook, for example, asks in order:

1. Was the payment released? If not, the case follows the internal processing route.
2. Was the network ACK received? If not, the case becomes a messaging investigation.
3. Did the downstream institution accept the payment? If not, it is a counterparty exception.
4. Is the nostro debit confirmed? If not, it becomes a settlement investigation.
5. Is a return present? If so, the return information is provided. If not, downstream status is requested.

Runbooks are versioned. Every historical case identifies the runbook version that was applied.

SWIFT Exceptions and Investigations

SWIFT is moving investigations and cancellations to ISO 20022 messages. PaymentOps handles the structured messages and the transitional and legacy workflows side by side.

Purpose	ISO 20022	Legacy equivalents
Investigation request	camt.110	MT195, MT198, MT295, MT298 and MT199/299 workflows
Investigation response	camt.111	MT196, MT198, MT296, MT298 and MT199/299 workflows
Payment cancellation request	camt.056	MT192, MT292
Payment cancellation response	camt.029	MT196, MT296

SWIFT's published transition requires institutions to receive camt.110 investigation requests with in-flow translation from November 2026. Full exchange of investigation requests and responses through Case Orchestrator using camt.110 and camt.111 is mandatory from November 2027, when payment cancellations also move to Stop and Recall using camt.056 and camt.029 over FINplus.

• Receiving a camt.110. PaymentOps ingests the message, parses the investigation details, extracts the UETR, associates the case with the existing canonical payment and creates the case automatically. The transitional embedded MT199 workflow is supported where it applies.
• Answering with a camt.111. PaymentOps generates the structured response, validates the required data, shows a human-readable preview, applies maker/checker approval, sends it through the configured Case Management integration and records network acknowledgements and status.
• Cancellations. PaymentOps supports camt.056 and camt.029, Stop and Recall integration, cancellation status tracking and prevention of duplicate cancellations.

Collaboration

Cases support comments, @mentions, attachments, internal notes, external communications, handoffs, escalation and linked incidents. Internal comments and externally transmitted communications are clearly distinguished.

Knowledge

Operational knowledge is attached to exception codes, message types, counterparties, runbooks, incidents and previous resolutions. An operator who receives an exception code such as AC03 sees the relevant internal procedures and historical patterns immediately.

Export

Authorized users export cases and evidence packages. A case export contains the case metadata, payment summary, timeline, evidence, messages, decisions, approvals, communications, final resolution and audit history.

Actions and approvals

Actions

Everything PaymentOps does to a payment or case is an action. Actions include opening or responding to an investigation, requesting status, requesting or approving a cancellation, retrying a payment, resubmitting screening, escalating or assigning a case, creating an incident and notifying customer service.

Every action defines its source system, the permission required, its inputs, validation, the approvals required, the execution mechanism, the result and a reconciliation or verification step. An action is never reported as successful merely because the request was submitted. It moves through four states:

State	Meaning
Requested	The action was submitted by a user or by automation.
Sent	The request was delivered to the executing system.
Acknowledged	The executing system accepted it.
Confirmed	Downstream confirmation was received and verified.

Write actions carry unique request identifiers and are safe to retry, with duplicate detection and downstream confirmation.

Maker/checker approval

Four-eyes approval, also called maker/checker, means that one person prepares an action and a different person approves it before it runs. High-risk actions support it. Each customer configures its own policies. An example policy:

Action	Approval
Investigation response below 1 million euros	Single approval
Investigation response of 1 million euros or more	Maker/checker
Cancellation	Always maker/checker
Manual correlation override	Senior operator

Automation policies

Automation is always explicitly configured. A policy states the conditions under which PaymentOps may prepare or send a response, and the exceptions that require human review. For example, a policy for credited claims of non-receipt applies only when the original payment is found, the final ledger posting is confirmed, no return exists, data is fresh and the amount is below a set limit. It then sends the response automatically, except for VIP customers, whose cases need human review.

Automation is offered in five levels, and each customer chooses how far to go:

Level	Behaviour
0	Manual
1	Automatic evidence gathering
2	Recommended resolution
3	Action prepared automatically and held for approval
4	Straight-through resolution for explicitly permitted scenarios

Configuration management

Runbooks, correlation rules, thresholds, permissions, SLA policies and automation rules are treated as regulated configuration. A change is prepared, reviewed, approved, scheduled, made active and eventually superseded. Every case identifies the configuration version used, and banks can express their own procedures, such as VIP escalation, amount-based escalation, correspondent-specific workflows, cut-off handling, currency-specific processes and market-calendar rules, without code changes.

Incidents, SLAs and notifications

Incidents

A case concerns one payment. An incident concerns a common problem that affects many. PaymentOps detects patterns such as a sudden rise in rejection rate, missing acknowledgements, correspondent latency, stalled payments, infrastructure outages, scheme-specific errors, unusual return rates and spikes in message-validation errors.

An incident shows when it started, how many payments and how much value it affects, the baseline and current rejection rates, the primary response code and the likely affected flow. Individual exceptions can be attached to it.

Root-cause assistance

PaymentOps correlates incidents with operational changes such as software deployments, configuration changes, routing changes, schema releases and correspondent outages. It keeps observed fact separate from suggested cause. For example, a fact that the rejection rate rose at a stated time and a fact that a payment hub release completed shortly before are shown as facts. The statement that the deployment may be related is shown as a hypothesis with a stated confidence.

SLA management

SLAs are configurable by case type, client, payment type, amount, corridor, business calendar, institution and priority. Each supports a warning threshold, a breach threshold, pause conditions and escalation rules. The SLA policy version in effect when a case was created is retained with the case.

Notifications

Notifications are sent through the application, email, Teams or Slack where permitted, webhooks, ServiceNow or a customer-specific integration. Typical notifications are a new P1 exception, a case approaching its SLA, correspondent degradation, an approval required and a case response received. Notification frequency is configurable to prevent alert flooding.

Analytics

Analytics are built to be acted on. Metrics are grouped as follows.

Area	Metrics
Processing	Total payment volume, STP rate, rejection rate, return rate, processing latency
Exceptions	Exceptions per 1,000 payments, causes, value affected, average exception age
Investigations	Cases opened, average and median resolution time, SLA breach rate, automation rate, cases per operator
Counterparties	Rejection rate, response latency, investigation frequency, return frequency
Automation	Automatically resolved cases, suggested resolutions accepted and rejected, false-positive automation alerts

STP (straight-through processing) is a payment that completes without manual intervention. Authorized users can export the underlying datasets.

AI assistance

AI in PaymentOps is supportive and never authoritative. It works from a structured evidence context supplied by the deterministic layers, and it is used for:

• Payment explanation: turning technical events into a readable explanation.
• Case summaries: condensing long investigation histories.
• Response preparation: composing a reply from facts already verified by deterministic systems.
• Similar cases: finding historical cases with similar characteristics.
• Procedure retrieval: identifying the relevant operating procedure or runbook.
• Natural-language search: turning a request such as "EUR payments above 1 million sent through a named correspondent today without downstream confirmation" into structured search criteria.

Guardrails

The language model does not independently decide whether settlement legally occurred, whether sanctions screening should pass, whether a suspicious activity report should be filed, whether funds should be released or whether a cancellation is legally permissible.

• Every suggested statement displays its evidence: the message, its status, its identifier and its source.
• Generated text is clearly identified as generated until a person approves it.

Security, access and audit

Access control

PaymentOps supports role-based and attribute-based access control. Permissions can depend on legal entity, country, branch, payment rail, currency, account, customer classification and action type. A user might be able to read payments of one legal entity, respond to investigations below a set amount, never cancel, view raw customer data and not view sanctions details. Actions a user cannot take are not offered.

Masking

Masking is configurable for account numbers, IBANs, names, addresses, remittance data and internal identifiers. Different roles receive different views of the same payment.

Authentication

PaymentOps signs users in through SAML 2.0, OIDC and enterprise single sign-on, with multi-factor authentication provided by the identity provider. Local production passwords are disabled by default.

Platform security

Controls include TLS in transit, strong encryption at rest, secrets-management integration, key rotation, least-privilege service accounts, network segmentation, full audit logging, configurable data residency, vulnerability management, signed software artifacts and a secure software development lifecycle. Customer-managed encryption keys are supported.

Audit trail

Every meaningful user or automated action creates an immutable audit entry. An entry records the timestamp, the user or service, the action, the entity, the previous and new state, the source IP, the approval, the reason, the policy version, the runbook version and the evidence. Audit data can be exported for external audit. Auditors have read-only access to case history, approvals, operator activity, source messages, automated decisions and the configuration in effect at the time of each decision.

Deployment

PaymentOps is available as vendor-managed SaaS, as a dedicated SaaS tenant or environment for one customer, or deployed into the customer's own AWS, Azure or Google Cloud subscription.

Operating PaymentOps

PaymentOps exposes metrics, structured logs, distributed traces, health endpoints, queue lag, connector status and workflow latency, and integrates with platforms such as Splunk and Datadog.

Integrations and messages

Connectors

A connector is a configured link between PaymentOps and one source or destination system. Connectors are a platform capability, not one-off integrations. Each defines its type, direction, protocol, authentication, schema, checkpoint, retry policy, health and mapping. Supported transport patterns are REST, SOAP where necessary, Kafka, IBM MQ, JMS, SFTP and file, database read replica, event stream and webhook.

Category	Systems
SWIFT	Alliance Access, Alliance Messaging Hub, Case Management, Stop and Recall, and Tracker information where licensed and available
Payment hubs	Finastra Global PAYplus, FIS Open Payments Framework, ACI Enterprise Payments, Volante VolPay, Temenos Payments and custom payment engines
Screening	LexisNexis Firco, NICE Actimize, Eastnets and customer-built systems
Case and ITSM	ServiceNow, Jira and internal case managers
Core and ledger	Customer-specific integrations

Connector health

Every connector exposes its last successful event, current lag, messages processed and failed, error rate, connection status and schema version, so operations teams know when PaymentOps has incomplete information.

Supported messages

The parser architecture is extensible. Supported messages are:

Group	Messages
Cross-border payments	MT103, MT202, MT202 COV, pacs.008, pacs.009, pacs.002
Cash management	camt.052, camt.053, camt.054
Investigations and cancellations	camt.110, camt.111, camt.056, camt.029, the relevant MT19x and MT29x messages and unstructured investigation messages during the transition
Network events	ACK, NAK, delivery information, FIN and FINplus metadata, UETR and Tracker information where accessible

Domestic schemes are added through plug-ins.

APIs and webhooks

PaymentOps exposes APIs with a consistent idempotency and authorization model.

Area	Endpoints
Payments	GET /payments, GET /payments/{id}, GET /payments/{id}/events, GET /payments/{id}/messages
Cases	GET /cases, POST /cases, GET /cases/{id}, POST /cases/{id}/actions
Incidents	GET /incidents, GET /incidents/{id}
Actions	POST /actions, GET /actions/{id}

Webhook events are payment.exception.created, case.created, case.sla.warning, case.resolved, incident.created and action.approval_required.

Customer-service view

PaymentOps can expose a sanitized payment status to customer-service teams, so they can answer "where is this payment?" without payment-operations permissions. The view says whether the payment was sent, whether the receiving institution accepted it, whether a return was received, whether an investigation is open and the case reference.

Roles

Role	Uses PaymentOps to
Payment operations analyst	Resolve failed payments, respond to investigations, repair payments, trace transactions, answer customer requests and monitor queues, using a small number of optimized screens.
Senior analyst	Handle complex exceptions and escalations with full technical evidence, raw messages, advanced search, override capabilities, escalation controls and historical cases.
Operations manager	Follow workloads, SLA performance, exception volumes, operational risk, staffing, incidents and correspondent performance in dashboards.
Payments product owner	Identify systemic processing problems, expensive corridors and recurring rejection causes.
Engineering and production support	Inspect exact system events, message payloads, timestamps, routing decisions, source-system identifiers and correlation chains.
Compliance operations	Contribute evidence or resolve compliance holds, with access limited to permitted payment information.
Auditor and risk	Read case history, approvals, operator activity, source messages, automated decisions and the configuration in effect at decision time.
Platform administrator	Manage users, roles, integrations, rules, runbooks, queues, retention, masking and environments.

The interface is built for expert, keyboard-driven work: fast keyboard navigation, a command palette, saved searches, configurable columns, copyable identifiers, deep links, compact information density and use across multiple monitors. Common tasks avoid modal dialogs.