Use case · Payments operations
Reconcile every payment provider from one operational view.
Give payments and finance teams a purpose-built interface for reconciliation, fees and exceptions. Nexus connects the underlying systems, runs the matching logic and governs every exception behind the scenes.
- Purpose-built business interface
- Deterministic matching
- Human-reviewed exceptions
- Auditable workflow
The operational problem
Every provider reports differently, and the gaps surface late.
Operators that accept payments through several PSPs and acquirers reconcile settlement files, bank statements and internal transaction records that were never designed to agree with each other.
Fragmented sources
Settlement data arrives through provider APIs, file drops and email attachments, each with its own fields, timing and identifiers.
Manual matching
Spreadsheet matching against internal records is slow to repeat and hard to apply the same way every time.
Opaque fees
Fee layers are bundled into settlement amounts, so discrepancies are difficult to see until month end.
Untracked exceptions
Unmatched transactions move between inboxes and sheets without a single record of who investigated and what was decided.
Built for the business. Powered by Nexus.
The business works in its own interface. Nexus runs underneath.
The people doing the work never open a workflow builder. They use an interface designed for their role, and Nexus handles integrations, rules, code, AI where useful, exceptions, approvals and audit.
Built for the business
Purpose-built interface
- Reconciliation status by provider and period
- Fee visibility where source data provides fee layers
- Exception queue with investigation context
- Review, approve and resolve actions
Powered by Nexus
Orchestration engine
- Ingestion from APIs, SFTP, monitored email and databases
- Normalization into one transaction shape
- Explicit, versioned matching rules
- Fee logic, exception routing, approvals and audit
Workflow
How the workflow runs
Every run follows the same governed path. Deterministic rules do the matching; people decide what the rules cannot.
- 01
Ingest
PSP, acquirer, bank and internal records arrive through APIs, SFTP or file drops, monitored email or database connections.
- 02
Normalize
Rules + Code converts each source into one transaction shape with provider, amount, currency, reference, type, status and timing.
- 03
Match
Explicit, versioned rules match transactions against internal records on amount, timing, reference, type and status.
- 04
Apply fee logic
Configured fee logic analyses fee layers where the source data provides them and flags differences from expected fees.
- 05
Route exceptions
Unresolved or ambiguous items go to the exception queue with the source records attached. AI can help classify unstructured cases; it does not approve anything.
- 06
Human review
Payments and finance staff investigate, resolve and approve exceptions in the business interface.
- 07
Audit
Decisions, rule versions and workflow actions are recorded in the audit trail.
Business interface
What the business team sees
A custom payments operations interface designed for the role. It is not the Nexus workflow builder; it reads from and writes to Nexus underneath.
PSP A
Reconciled
PSP B
Exceptions open
PSP C
Awaiting file
Bank feed
Reconciled
Exception queue
| Reference | Provider | Reason | Status |
|---|---|---|---|
| TX-SAMPLE-01 | PSP A | No internal match | In review |
| TX-SAMPLE-02 | PSP B | Fee differs from expected | Open |
| TX-SAMPLE-03 | PSP B | Timing outside window | Open |
| TX-SAMPLE-04 | PSP C | Duplicate reference | Resolved |
Transaction drill-down
- Provider record
- PSP B settlement line
- Internal record
- Candidate match found
- Rule result
- Amount matched, fee differs
- Rule version
- Matching rules, current
Architecture
Three layers, one governed process.
The interface, the orchestration and the systems of record stay separate. Each keeps its own responsibility.
Purpose-built business interface
Payments / Finance UI
- Reconciliation status
- Fee visibility
- Exceptions
- Review / approve / resolve
Nexus orchestration layer
- 01Ingestion
- 02Matching rules
- 03Fee logic
- 04Exception routing
- 05Human approval
- 06Audit
Systems · Data in
- PSP settlement data / APIs
- Banks
- Internal transaction records
Systems · Data out
- ERP / accounting
- Alerts / notifications
- Archive / reporting
Why Nexus
Why Nexus fits regulated payment operations
Deterministic control
Matching and fee logic are explicit, versioned rules, so the same input produces the same result and every change is reviewable.
Human approval for money decisions
Adjustments and resolutions pass a named human approval step. AI assists with ambiguous cases and never approves money movement.
Evidence by default
Each run records inputs, rule versions, decisions and actions, giving finance and audit one trail to review.
Runs where you need it
Nexus deploys in your own cloud, on premises or air-gapped, so transaction data stays inside the environment you control.
Any provider, governed
Providers without a pre-built connector connect through API, SFTP, email or database steps with the same approvals and audit.
Practical outcomes
What changes for the team.
- Fewer manual reconciliation steps across providers.
- Earlier visibility into unmatched transactions and fee discrepancies.
- Consistent exception handling with the same rules every run.
- Traceable approvals for every resolution and adjustment.
- Easier onboarding of new providers through governed integration patterns.
FAQ
Questions about this use case
How is this different from a reconciliation-only tool?
The business team works in an interface built for reconciliation, and Nexus runs the full process underneath: ingestion, normalization, matching rules, fee logic, exception routing, human approval and audit, plus onward actions into ERP, alerts and reporting. The same platform can run other finance and operations workflows.
How can Nexus ingest PSP data?
Through provider APIs, SFTP or file drops, monitored email inboxes and database connections. Each source is normalized in Rules + Code into one transaction shape before matching.
Does AI approve transactions or payments?
No. Matching and fee checks run on deterministic rules, and resolutions or adjustments require human approval. AI can help classify ambiguous or unstructured cases for the reviewer.
Can exceptions require human review?
Yes. Unresolved or ambiguous items route to an exception queue, and the workflow waits for a person to investigate, resolve or approve before it continues. Each decision is recorded in the audit trail.
Where does the workflow run?
Nexus runs in your own cloud, on premises or in an air-gapped environment, so transaction data and workflow evidence stay inside the environment you choose.
Can we add a local or niche PSP?
Yes. A provider without a pre-built connector connects through its API, SFTP or file delivery, email or a database, and its records join the same normalization, matching, approval and audit path.
Related customer story
Payment reconciliation for a betting & gaming operator
Multi-pass matching between internal transactions and payment-provider records, with managed exceptions and role-scoped dashboards.
Read the customer storyArchitecture session
Map your payments reconciliation workflow.
Tell us which providers, banks and internal systems are involved and where exceptions slow you down. We will sketch the interface, rules and approval points with you.