UNIFINplatform

Solution

Unifin Instant Payments

Instant payments win where a transfer is fast and a dispute is fair.
The suite starts a payment by an alias: payee check, anti-fraud, pacs.008, netting.
Holds stay with the operator, disputes follow the term, the trail leads to settlement.

  • Transfers 24/7
  • Netting
  • Deadline control
All solutions

Live screens from the product terminals

Operations registry screen with transfers and statuses Operations registry screen with transfers and statuses Suite monitoring screen with SLA and queues Suite monitoring screen with SLA and queues Alias registry screen with bindings
Demo Unifin Instant Payments Theme Open separately
Payment overview
Payment overview

This is an interface demonstration: the real solution will differ in colours and content for a specific project.

Functions at a glance

Business functions at a glance

From alias intake to holds and the journal.

Alias intake
Resolves phone, e-mail, QR or R2P into an account
A transfer starts without account details
VoP and anti-fraud
Checks the payee and scores before execution
Fraud stops before the money moves
Execution and statuses
Executes pacs.008 and returns the statuses
The initiator sees the fate of a transfer
Clearing and liquidity
Nets positions and keeps the limits
A liquidity shortfall closes in the window
Settlement with the bank
Runs ISO 20022 instructions to the settlement bank
The netting cycle is confirmed and reconciled
Disputes and returns
Runs camt.056 and camt.029 by the rulebook term
A dispute closes within the term
Holds and journal
Keeps holds under operator control
Every decision is confirmed by a person

What runs today

Instant flows, already running

Alias to settlement: the live flow.

Alias

The alias registry resolves the payee.

VoP

Verification of payee and anti-fraud checks run before sending.

pacs.008

ISO 20022 pacs.008 flows carry the transfer.

Netting

Clearing and netting run inside the circuit.

Disputes

Disputes and returns follow the term control.

Roadmap

Richer alias types are next.

Solution description

Capabilities and overview

Key features

  • Alias intake: phone, e-mail, QR or R2P
  • Verification of the payee before the transfer executes
  • Anti-fraud checks with scoring before dispatch
  • Transfers 24/7 in the ISO 20022 pacs.008 format
  • Netting cycles with liquidity control
  • Settlement with the settlement bank by ISO 20022 instructions
  • Disputes and returns within the rulebook term
  • Holds under the control of the suite operator
  • Transfer statuses at every step with a journal
  • Notifications to the sender and the payee
  • Journal and audit for every transfer and decision
  • Deployment: by configuration, within the UniFin platform

Product overview

Unifin Instant Payments is the UniFin platform instant payment suite for participant banks and settlement infrastructure operators.

The suite starts a payment by an alias: payee verification, anti-fraud, pacs.008 execution, netting and settlement with the bank.

Holds stay under operator control, disputes follow the rulebook term, and the trail leads to settlement.

Statuses and notifications come at every step, while the journal explains every decision of the system.

The solution runs within the UniFin platform and connects to the bank and adjacent suites through ISO 20022 channels.

What it delivers

What the solution delivers

Alias intake

Transfers usually require account details, and the client dictates them over the phone. The solution resolves phone, e-mail, QR or R2P into an account and a participant through the alias registry. With the solution the transfer is simpler, and input errors are fewer. In setup the bindings and the revocation history are visible, and the registry rules come as reference data.

VoP and anti-fraud

Fraud usually surfaces after the transfer, when the money is gone. The solution checks the payee name and scores anti-fraud before execution. With the solution the suspicious is stopped before the money moves. In setup the rule thresholds and the stop factors are visible, and the rules are set in configuration.

Execution and statuses

The status of a transfer is usually clarified by calls to support. The solution executes pacs.008 and returns pacs.002 statuses to the initiator. With the solution the fate of every transfer is visible without manual requests. In setup the route and the status timeline are visible, and the formats are configured per segment.

Clearing and liquidity

Netting is usually computed in one batch at day end, and positions are visible with a delay. The solution nets positions in five-minute cycles. With the solution liquidity is visible in the moment, and a shortfall closes in advance. In setup the limit gauges and the top-up window are visible, and the cycle mode comes as reference data.

Settlement with the bank

Settlement is usually confirmed by correspondence with the bank. The solution runs ISO 20022 instructions to the settlement bank. With the solution the cycle confirmation arrives, and the net reconciles without manual work. In setup the instruction statuses and the reconciliation are visible, and the schedule comes as reference data.

Disputes and returns

Disputes usually go by letters and run past the rulebook term. The solution runs camt.056 and camt.029 exchange and cases with the term. With the solution disputes close on time and predictably. In setup the correspondence and receipts per case are visible, and the terms come from the setup.

Holds and journal

Releasing a hold usually lives in shift chat. The solution keeps holds under operator control with a basis. With the solution every decision about client money has a trail. In setup the hold journal and the exports are visible, and the hold rules are part of the configuration.

Coverage

What it covers

The alias becomes an account; checks run, the cycle nets.

Intake and alias registry

Transfers 24/7, alias resolution, bindings of phone, e-mail, QR and R2P.

Transfers and routing

Transfer orchestration, pacs.008 execution, pacs.002 statuses and recovery.

VoP and anti-fraud

Payee verification before execution, anti-fraud rules with thresholds, scoring and stop factors.

Clearing and liquidity

Netting of participant positions, limit control and liquidity top-up.

Settlement

ISO 20022 instructions to the bank, cycle confirmations and reconciliation.

Disputes and returns

Return requests, camt.056 and camt.029 exchange and cases with the rulebook term.

Notifications

Statuses for participants and clients and events for external systems.

Journal and audit

Operation tracing from alias to settlement; holds and rules in the journal.

Stand

Screens of the solution

The operations registry, the alias registry and the suite pulse.

Operations registry screen with transfers and statuses
Operations: from transfer to settlement, with statuses, filters and the day totals
Alias registry screen with bindings
Alias registry: bindings, payee verification and statuses
Suite monitoring screen with SLA and queues
Suite monitoring: SLA, queues, anti-fraud rules and events

How it works

From an alias to the settlement in five steps

The transfer path: alias intake, checks, the run, the cycle, settlement.

  1. 1

    The transfer is initiated by an alias

    A transfer comes by alias; the registry resolves the account.

  2. 2

    Protection before execution

    VoP matches the payee name; the anti-fraud score runs before execution.

  3. 3

    Execution

    A positive decision executes pacs.008; pacs.002 reaches the initiator.

  4. 4

    Clearing every five minutes

    The cycle nets participant positions; a shortfall triggers a liquidity top-up.

  5. 5

    Settlement and notifications

    The bank confirms the cycle; statuses and statements leave the suite.

Industries

Industries it serves

The suite serves participant banks, payment services and wallets, businesses with payout flows, central infrastructure and supervisors. The operators of the settlement circuit.

Exchange / venue

Trading, supervision, market data and post-trade on one governed core, launched by configuration.

Corporate / issuer

Market access for producers and issuers: auctions, deliveries, tokenised assets and data.

Regulator / supervisor

Surveillance evidence, market analytics and reporting built from live transaction data.

Architecture

Architecture and access

The architecture rests on the payment core and the operations portal. An alias registry and intake, VoP and anti-fraud, transfers and routing, clearing and liquidity, settlement, disputes and returns.

Service suite

The operations portal, the alias registry, VoP and anti-fraud, transfers, clearing, settlement and disputes.

External suites stay external

Bank cores, the settlement bank, the supervisor and notifications connect as connectors.

Multi-region and DR

Active-active read with replicas and a DR region for Tier-0; Active-Passive clusters allowed.

Extend without touching the core

A new channel, rule or connector joins through base services and reference data: the core stays still.

AI layer

The AI layer highlights queue anomalies and drafts the dispute summary; people approve.

Architecture scheme The same architecture as a standalone page. Open the diagram separately

Readiness

Ready today, next in line

The base is in place; next: request-to-pay scenarios and bulk payouts.

Ready today

  • Intake by alias, VoP and the anti-fraud score before execution
  • Transfers pacs.008 with pacs.002 statuses and operator holds
  • Netting, net positions and limit gauges
  • Disputes and returns with the rulebook term

Next in line

  • Request-to-pay scenarios for merchants
  • Bulk payouts with duplicate control on the portal
  • More supervisory export formats (roadmap)

Releases

Release history

Quarterly releases from the foundation of the platform (2020); the instant payment suite launched in 2026.

2026 Q1

  • Intake and the alias registry: transfers by phone, e-mail, QR and R2P.

2026 Q2

  • VoP, anti-fraud and scoring rules, clearing and liquidity.

2026 Q3

  • Returns and disputes over camt.056 and camt.029.

2026 Q4

  • Request to pay and bulk payouts (plan).

Detailed description

Detailed description

The module map, the rule set and the delivery frame.

How the suite is assembled

Channels and clients
FIX 4.2 / 4.4 / 5.0, REST with mTLS, SFTP files, web portals
Edge and access
API gateway with 126 routes, Keycloak single sign-on, WAF and CSP
Platform core services
payment-ms clearing-ms risk-ms notification-ms AI agentic layer Services of the suite on the shared platform core
Data and events
PostgreSQL 17 per service, Redis 7, RabbitMQ 3.13 quorum queues, transactional outbox
Results and reporting
Portals, reports, regulator and partner channels

Technology stack

Runtime and backend: Java 21 (LTS), Spring Boot 3.5.16, Spring Cloud 2025.0.3, Gradle, Flyway 10.15.

Data: PostgreSQL 17, Redis 7 with Sentinel, RabbitMQ 3.13 with the transactional outbox.

Exchanges: ISO 20022 (pacs.008, pacs.002, camt.056, camt.029); OpenAPI for every service.

Portals: Next.js 16.3.3, React 19, TypeScript 5; Onest typography and two themes; Keycloak 26.1 for OIDC sign-in.

Delivery: Kubernetes and Helm, Vault secrets, Prometheus and Grafana, Docker Compose for pilots.

Evidence by default: every hold, rule change, export and return is journaled for five years.

Intake and the alias registry

  • A transfer starts by an alias: phone, e-mail, QR or R2P; the registry resolves it into an account and a participant within 200 ms.
  • Transfers run 24/7 with no night or weekend windows: 2.41 million operations a day, a median of 3.1 seconds and p99 at 4.2 seconds.
  • A revocation of an alias keeps its history; the registry shows bindings, statuses and the channel of every binding.
  • Routing picks the participant and the account; duplicates are cut by idempotency keys.

Protection: VoP, anti-fraud and limits

  • VoP matches the payee name before execution; the 92% match across the suite is shown to the initiator.
  • Anti-fraud runs 64 rules before funds are debited: velocity 38%, behaviour 31%, blocklists 18% and geography 13%.
  • The false-positive rate is 4.1%; a hold waits for the operator with a visible timer, and 18 held operations carried 41.2 million USD per shift.
  • The position limit warns at 80% and stops at 100%; a shortfall opens a top-up window of 60 seconds.

Clearing and settlement

  • Netting runs every five minutes: 288 cycles a day close participant positions and publish the net.
  • Transfers execute as pacs.008 with pacs.002 statuses back to the initiator; settlement is confirmed by the settlement bank.
  • Coverage is kept at 142% against the 108% minimum; the gauges are on the clearing window.
  • Reconciliations of the net and the cycle journals are reproducible for the supervisor.

Disputes and returns

  • A return request travels as camt.056 and the answer as camt.029; the case keeps correspondence and grounds.
  • The five-business-day standard is tracked with a timer; the average case closes in 2.4 days and 23 of 312 disputes stay open.
  • Returns account for 0.38% of operations; escalation follows the channels of the participants.
  • A human confirms every return release, and the journal records it.

Architecture

  • Built from the platform core: payment-ms, clearing-ms, risk-ms and the notification suite behind a portal BFF.
  • The portal BFF keeps roles, routing and audit; a window knows only its own /api/v1 calls.
  • Bank cores, the settlement bank, the supervisor and notification channels connect as connectors and reconciliations.
  • Scaling adds nodes: Patroni, RabbitMQ quorum queues and Redis clusters; stateless services run in three zones.
Detailed description

Leave your contacts to open the detailed description and download the PDF with architecture, cases and delivery details.

Ask about the payment suite

Bring one transfer and one clearing cycle. We will show the path from an alias to the settlement and from a hold to the dispute.