About this article. This is a general, informational overview of RTSP’s Managed Refunds product, combined with vendor-neutral context about the wider problem it addresses – distributing refunds to large numbers of people accurately and compliantly. Specific product facts, figures, and integrations described below reflect how RTSP presents the product publicly; the surrounding explanation of bulk-refund controls is generic domain knowledge that applies to this class of problem generally. Nothing here is legal, regulatory, compliance, or financial advice, and requirements vary by organisation and jurisdiction.
The one-line version
Refunding a single customer is trivial. Refunding forty thousand of them – correctly, once each, to the right bank account, with an audit trail an auditor or a court would accept – is a controls problem. RTSP Managed Refunds is built to solve that controls problem: it takes a list of people owed money and turns it into a validated, approved, reconciled batch of payments disbursed over Australian payment rails, with the results posted back into the finance system.
What RTSP is
RTSP (operated by Riparian Services Pty Ltd, based in Brisbane, Australia) positions itself as a settlement layer that specialises in moving money in and out of a finance system in a way that ties cleanly back to the general ledger, built for Australian payment rails. It has deep, native integration with Microsoft Dynamics 365 and the surrounding Microsoft data platform – that is where the product is most turnkey – but Managed Refunds is not restricted to Dynamics. The core engine (ingest, validation, calculation, approval, disbursement, and reconciliation) is finance-system-agnostic and can be integrated with other ERPs, accounting systems, or bespoke back-office platforms with customisation. Dynamics 365 is the fastest path in; it is not the only one.
Managed Refunds is one of its products. It is described as a working, in-production application rather than a concept: RTSP notes it is live at two founder-owned operating companies and is opening to design partners, emphasising that it runs on real operational data rather than being “a slide.”
The problem it addresses
Most refund tooling is built around the everyday case: a customer returns an item or disputes a charge, and one payment goes back to one person. That model breaks down badly when an organisation suddenly has to pay many people at once. Several situations create exactly that need:
- Class-action and legal settlement distributions, where a settlement fund must be split across thousands of claimants according to a defined formula.
- Deposit and pre-payment returns, where large numbers of customers are each owed back money they paid up front.
- Health procedure refunds, where the amount actually charged differs from the amount quoted, and the difference must be returned to each patient.
In each case the difficulty is not the arithmetic of a single refund – it is doing thousands of them without paying the wrong person, paying twice, paying the wrong amount, or being unable to prove afterwards exactly what was paid to whom and why. That is a governance and reconciliation challenge as much as a payments one, and it is the gap Managed Refunds targets.
How it works: the three-step flow
RTSP describes Managed Refunds as a three-stage pipeline. The stages map neatly onto the three things that actually go wrong in bulk refunds – bad data, unapproved or miscalculated amounts, and payments that don’t reconcile – and put a control in front of each.
Step 1 – Ingest & Validate
The system loads payee files from any source – legal registers, booking systems, hospital patient-administration (PAS) exports – in common formats such as CSV, Excel, or PDF. It then cleans and checks that data before any money is involved: it deduplicates records so the same person is not paid twice, validates banking details, and screens against compliance rules.
This front-loaded validation is the single most important idea in bulk refunds. Because a batch payment run pushes money out in volume, every error in the input list is multiplied. Catching duplicates, malformed account details, and ineligible payees before the run – rather than chasing them afterwards – is what makes the rest of the process safe.
Specific validation capabilities RTSP highlights include:
- Identity matching with confidence scoring, so records that may or may not refer to the same person are flagged rather than blindly merged or paid.
- Bank account validation of Australian details – BSB, account number, and PayID.
- Confirmation of Payee (CoP) integration for real-time verification that the account name matches the intended recipient — a direct defence against misdirected payments and certain fraud.
- A patient self-service portal allowing individuals to securely enter their own bank details, which both improves accuracy and shifts the data-entry burden to the person who actually knows their account.
Step 2 – Calculate & Approve
Once the payee list is clean, refund logic is applied per payee. Different use cases need different calculations, and the product supports several: fixed shares (as in a settlement split), deposit returns, and estimate-versus-actual deltas (as in the health case, refunding the difference between a quote and the final cost).
Crucially, calculation is paired with maker-checker approval workflows and full audit evidence. Maker-checker (also called four-eyes) means the person who prepares a refund run is not the same person who approves it — a standard financial control that prevents both error and fraud from passing through unreviewed. In a settlement or health-refund context, being able to demonstrate that every amount was calculated by rule and independently approved is often not optional; it is what makes the distribution defensible to a court, a regulator, or an auditor.
Step 3 – Pay & Post
Approved refunds are disbursed over Australian rails – OSKO/NPP (the New Payments Platform, for fast account-to-account payments) and BECS (the batch direct-entry system for bulk bank transfers) – through the client’s existing bank channel. The results are then posted back into the finance system – natively into Dynamics 365 where that is the system of record, or into another ERP or ledger via the appropriate integration – hitting the general ledger and bank-clearing accounts.
Two design choices matter here. First, paying through the client’s own bank channel (rather than a third-party wallet or pooled intermediary) keeps the organisation in its established banking and control relationships. Second, posting results straight back into the ledger closes the reconciliation loop automatically – the payments that went out are recorded without a manual re-keying step, which is where bulk refunds usually leak accuracy. That posting is out-of-the-box for Dynamics 365 and can be mapped to other finance systems as part of an implementation.
Key features at a glance
Drawing the pieces together, the product’s notable capabilities include:
- Bulk ingestion from CSV, Excel, and PDF sources such as legal registers, booking systems, and hospital PAS exports.
- Identity matching with confidence scoring and deduplication.
- Bank-detail validation (BSB, account number, PayID) plus Confirmation of Payee for real-time account-name checks.
- Per-payee calculation supporting fixed shares, deposits, and estimate-versus-actual deltas.
- Maker-checker approval with full audit evidence.
- Funding-pool reconciliation, ensuring the total disbursed matches the amount held – so a distribution can never quietly pay out more (or less) than the fund it is drawing from.
- Disbursement over OSKO/NPP and BECS through the client’s existing bank channel.
- Native Dynamics 365 posting into the general ledger and bank-clearing modules (using Microsoft Dataverse for reference data), with the same posting able to be mapped to other ERPs and ledgers through customisation.
- A patient self-service portal for secure entry of bank details.
- A white-label, multi-tenant architecture, allowing it to be operated across multiple entities or offered under another brand.
Integrations and technical footprint
Out of the box, Managed Refunds integrates deeply with the Microsoft finance stack and Australian corporate banking:
- Microsoft Dynamics 365 – General Ledger and Bank modules for posting and clearing (native, turnkey).
- Microsoft Dataverse – for reference data.
- Corporate banking channels – including CBA Direct Link, NAB Connect, Westpac, and ANZ.
- RTSP’s own BankBridge rails – the underlying connectivity RTSP uses to move funds.
Organisations already running Dynamics 365 and banking with the major Australian banks get the fastest, lowest-effort path, because the product slots into infrastructure they already have rather than asking them to adopt a new payments platform wholesale. But the Dynamics integration is a native accelerator, not a hard dependency: the ingest, validation, calculation, approval, disbursement, and reconciliation engine is designed to be integrated with other ERPs, accounting systems, or custom back-office platforms. Running a different finance system simply means that posting and reference-data connections are built as part of the implementation rather than being pre-wired.
The outcomes RTSP reports
RTSP cites several headline results for the product. According to its materials, Managed Refunds can process 40,000+ payees in a single refund run, achieves 99.9% first-pass payment success after validation, and compresses completion time from days to hours. As with any vendor-reported metric, these are best treated as claims to validate against your own volumes and data quality rather than guarantees – the “after validation” qualifier on the success rate is itself a reminder that the up-front data cleaning is what makes the payment leg reliable.
Why this class of product exists: the generic view
Stepping back from RTSP specifically, bulk or mass refund distribution is a recognised and genuinely hard category, and it is worth understanding why a dedicated tool earns its place.
Errors multiply in batches. A one-off refund with a wrong account number is a support ticket. The same error rate across 40,000 payments is a mass incident. This is why serious bulk-refund tooling front-loads deduplication, identity matching, and account validation — the cheapest place to fix a bad record is before the run.
Correctness must be provable, not just achieved. Settlements, health refunds, and deposit returns frequently sit under legal or regulatory scrutiny. It is not enough to pay the right amounts; an organisation must be able to evidence that each amount was derived by rule and independently approved. Maker-checker workflows and immutable audit trails exist to make the distribution defensible after the fact.
The money has to tie out. A distribution draws from a defined pool – a settlement fund, a set of deposits, a refund liability. Funding-pool reconciliation, matching total disbursed against total held, is what stops a run from over- or under-paying relative to the money that was actually set aside. Without it, the books do not close.
Destination verification prevents the worst failures. Paying the right amount to the wrong account is one of the most damaging outcomes in payouts. Confirmation-of-Payee-style checks, which verify that the account name matches the intended person before funds move, are increasingly a standard control precisely because instant, account-to-account payments are hard to reverse once sent.
Reconciliation back to the ledger is where accuracy is won or lost. If the payment system and the finance system are reconciled by hand, the reconciliation itself becomes an error source. Posting results directly into the general ledger – as Managed Refunds does with Dynamics 365 – removes that manual step and keeps the financial record aligned with what actually happened.
Who it’s for
The clearest fit is an organisation that periodically or continuously needs to pay refunds to large numbers of individuals and operates in Australia on domestic rails. Organisations already running Microsoft Dynamics 365 get the most turnkey deployment, but a different finance system is not a barrier – it is an integration to be built during implementation. Legal administrators handling settlement distributions, businesses returning deposits at scale, and healthcare providers reconciling quoted-versus-actual charges are the archetypal users. The white-label, multi-tenant design also suits a provider that wants to operate refund distribution on behalf of several client entities.
Practical considerations before adopting
For anyone evaluating a bulk managed-refund capability – RTSP’s or any other – a few questions tend to matter most in practice. How good is the input data, and how much cleaning will it need before the first run? Which rails and banks must be supported, and are they covered natively? What approval and audit evidence will satisfy the specific legal or regulatory context of the distribution? How is the funding pool held and reconciled, and who is accountable for it? And how are exceptions — failed payments, unmatched identities, disputed amounts – surfaced and worked, since even a 99.9% first-pass rate still leaves a meaningful queue at forty-thousand scale. The strength of a managed approach is that these questions get answered once, in a governed system, rather than improvised per distribution.
Conclusion
RTSP Managed Refunds tackles a specific, under-served problem: paying many people back at once, accurately and provably, on Australian rails, with the results landing cleanly back in the finance system – natively in Dynamics 365, or in another ERP or ledger with customisation. Its shape – ingest and validate, calculate and approve, pay and post — mirrors the three failure modes of bulk refunds and puts a control in front of each. Whether or not a given organisation adopts this particular product, the underlying lesson is broadly true: at scale, a refund stops being a payment feature and becomes a controls discipline, and the value of a managed layer is that it makes that discipline repeatable, auditable, and fast.
This article is a general, informational overview. Specific product capabilities, integrations, and performance figures reflect how RTSP publicly describes Managed Refunds and should be verified directly with RTSP for any procurement decision. Nothing here is legal, regulatory, compliance, or financial advice.