Case Studies
How RadixTrie gave a South African bank real-time DebiCheck payment insight on SQL Server
When new debit order regulation put a bank's payments migration under time pressure, RadixTrie built a SQL Server and T-SQL data platform that normalised ISO 20022 XML, applied the business rules and gave stakeholders real-time compliance dashboards.
Need a hand with this? Talk to a senior database DBA ↓By RadixTrie10 September 20264 min read
One big thing
A leading South African bank had to comply with new industry regulation governing the phasing out of non-authenticated early debit orders (NAEDO) and authenticated early debit orders (AEDO) in favour of DebiCheck. After several failed attempts, and with time running out, the bank needed a way to handle large volumes of non-static XML payment data, apply complex payment business rules and see its migration status in real time. RadixTrie built that capability end to end on Microsoft SQL Server.
The project at a glance
| Requirement | Migrate early debit orders from NAEDO and AEDO to DebiCheck under industry rules, after several failed attempts |
| Data | Large volumes of ISO 20022 XML whose structure was not static |
| What was built | Dynamic XML normalisation into a relational model, business rules in T-SQL, reconciliation to transactional sources, dashboards and notifications |
| Platform | Microsoft SQL Server and T-SQL, with Power BI for the dashboards |
| Outcome | Real-time migration and compliance view per product house, and independent reconciliation of payments, interchange charges and revenue |
Why it matters
Regulatory migrations in payments are not optional and the deadlines do not move. When the existing platform cannot produce the evidence the regulator and the business need, the risk is not just a missed date. It is the inability to independently verify what the bank is being charged, what it is earning and whether each product house is compliant. Solving that with a data platform, rather than waiting for a vendor roadmap, is what made the difference here.
The client context
The client is a South African bank. Its payments division was responsible for migrating early debit orders to the DebiCheck standard under strict implementation and migration rules set by the industry. Internal product houses such as vehicle finance and home loans each carried their own migration and compliance obligations, and management needed a single, current view across all of them.
The challenge
The DebiCheck data arrived as large volumes of ISO 20022 XML whose structures were not static. The existing payments platform and the traditional vendor solutions available to the bank could not dynamically normalise that data, and they did not apply the associated business logic that the bank needed for two things: independent verification of the cost of interchange transaction charges, and proof of DebiCheck migration compliance.
- Non-static XML payment data at volume, which fixed schemas could not absorb.
- Complex payment business rules that had to be executed consistently against that data.
- No real-time visibility of migration progress or compliance for the business or its product houses.
- Several earlier attempts had already failed and the regulatory clock was running.
What RadixTrie did
RadixTrie developed an end-to-end solution rather than a point fix. It normalised the dynamic ISO 20022 XML as it arrived, with notifications to stakeholders, then transformed and curated the data into a relational data model on SQL Server. Business rules were executed in T-SQL against that model, and the results were reconciled to the bank's transactional data sources.
- Dynamic normalisation of ISO 20022 XML into a governed relational model.
- Business-rule execution and reconciliation against transactional sources.
- Packaged data products with self-service analytics and dynamic dashboards for DebiCheck stakeholders.
- Stakeholder notifications built into the data flow.
The platform was built on Microsoft SQL Server and T-SQL, with XML processing, Oracle Database as a source, Qlik Data Integration, Microsoft Power BI for the dashboards and Microsoft .NET Core for the services around it.
The impact
Management and the internal product houses could monitor their DebiCheck migration and compliance in real time, and through self-service analytics could see the bank's DebiCheck performance relative to the industry. The benefit the bank described as existential was the ability to reconcile all payments, including interchange charges and revenue, against its core banking systems.
- Real-time monitoring of migration and compliance per product house.
- Self-service analytics on DebiCheck performance relative to the industry.
- Independent reconciliation of all payments, interchange charges and revenue against core banking.
What the client said
"This solution did not make my day, week or month, it made my year!" Payments lead at the client
"When the industry regulator compliments you on your solution you know you have done something great." Senior technology executive at the client
"It is easy to see the value that the RadixTrie team provides." Payments technology executive at the client
"You guys need to demo this to the Reserve Bank." Payments Association of South Africa
What came next
The bank asked RadixTrie to apply the same approach and methodology in two further areas: proactively reconciling and detecting differences on reconciliation accounts to improve accuracy, find root causes and reduce revenue losses, and tracking uptake and benefits on a new learning and development platform for employees.
DebiCheck and SQL Server: common questions
What is DebiCheck?
DebiCheck is South Africa's authenticated early debit order system: the account holder confirms the debit order mandate electronically with their own bank, once, when the contract starts. It replaces the older NAEDO and AEDO early debit orders.
Can SQL Server process ISO 20022 payment XML?
Yes. In this project the XML was normalised as it arrived, transformed into a governed relational model in SQL Server and processed with T-SQL business rules, even though its structure changed between files.
Why build the platform on SQL Server rather than wait for a vendor?
Because the deadline did not move and the available products could not normalise the changing XML or apply the bank's rules. With the model, the rules and the reconciliation in SQL Server, the bank could verify its own charges and compliance independently.
What this means for your SQL Server estate
Most SQL Server engagements we take on are about keeping production healthy: backups that restore, patching, performance and availability. This one shows the other side of the same skill set. When the data model, the rules and the reconciliation live in SQL Server and T-SQL, the people who understand the engine deeply are also the people who can build the platform that a regulatory deadline demands.
Related reading: what good SQL Server support looks like in South Africa, SQL Server to Azure migration, and our database services. More case studies are on the blog.
Need a hand with this?
Tell us what you run today and when it has to move. A senior database DBA will reply directly, usually within one working day. Prefer email or phone? Write to expert@radixtrie.com or call +27 10 143 0304, or use the contact page to book a 30-minute call.
TAGSSQL ServerT-SQLPaymentsDebiCheckCase StudySouth Africa