How to Convert ISO 20022 XML to a Relational Database

ISO 20022 XML solves the financial messaging problem.

It does not solve your data engineering problem.

Can your systems send, receive, and validate a pain.001 or pacs.008 message?

Good.

Can your analysts query payments, accounts, parties, agents, references, and statuses in SQL without XPath gymnastics?

That’s a totally different problem.

ISO 20022 messages are hierarchical, not relational.

Valid XML is only the starting point. The real job is preserving the business structure inside queryable database tables.

That is where ISO 20022 stops being a messaging format and becomes a data modelling problem.

This guide closes that gap.

To make ISO 20022 data searchable, queryable, and analytics-ready for your use case, you need to convert the XML hierarchy into relational tables.

That means preserving the core business structure: headers, payments, transactions, parties, accounts, agents, references, and parent-child relationships.

In this guide, I’ll show why ISO 20022 XML to database conversion gets messy, and how automation can turn ISO 20022 XML into SQL tables without manual code and brittle custom mappings.

I know you’re busy. Here’s a TL;DR for this blog post:

• ISO 20022 works well for messaging. It gives financial systems a common XML format for payments, accounts, parties, and status updates.
• It does not work as a database model. pain and pacs messages are hierarchical XML documents, not relational tables. You can query them only through XML-aware functions or XPath/XQuery-style logic, unless you first convert them into SQL tables.
• Loading XML is only step one. Storing raw ISO 20022 XML helps with archiving and inspection, but not with analytics.
• The hard part is relational modelling. You need tables, keys, and relationships that preserve the original payment hierarchy.
• Manual parsing gets fragile. XPath logic breaks when message versions, namespaces, optional branches, or counterparties change.
• Automation is safer for real-world projects that need to scale.
• Dedicated XML to SQL converters can read the ISO 20022 XSD and generate SQL-ready tables, mappings, and relationships automatically.

What Is ISO 20022 XML?

ISO 20022 is the financial messaging standard behind a huge part of the world’s money movement.

It uses XML as its data exchange format and is used by financial institutions in more than 70 countries.

ISO 20022 is not limited to payments. It covers 20 business domains, including payments, securities, cash management, and trade services.

So it’s not just one XML being moved around from one bank to another.

It is a family of message types used across a payment flow:

• One message can start a payment.
• Another can move it between institutions.
• Another can report its status.
• Another can show the final result in account reporting.

The figure below shows how these message types connect in a Payment Flow example:

A pain.001 message can initiate a payment. A pacs.008 message can move that payment between financial institutions. A pacs.002 message can report the payment status during processing. A camt.053 can report the account statement later; camt.054 can report debit/credit notifications.

All of them are ISO 20022 XML. And none of them are shaped like clean database tables.

ISO 20022 is useful because it provides a common way for systems to describe the same payment data.

That is why ISO 20022 shows up in payment workflows such as Swift CBPR+, SEPA, and Fedwire.

But that only solves the messaging problem.

Once ISO 20022 messages arrive in your systems, the goal is no longer just to receive them.

The goal is to analyse the data and answer business questions.

You are no longer just asking:

“What is ISO 20022?”

You are asking:

• “How many payments did we process this week?”
• “What was the total payment volume by currency?”
• “Which payments failed?”
• “Which accounts were credited or debited?”
• “Which transactions need investigation?”

These are simple questions to ask.

They are much harder to answer when the data is still buried inside nested XML.

That is where the engineering problem starts:

“How do I validate this XML, parse it, flatten it, store it, and query it without turning my pipeline into a pile of custom mappings?”

Continue reading to find out.

ISO 20022 Message Families and Types

ISO 20022 message types are not random XML files.

They are organised into message families, each covering a different stage of the financial transaction lifecycle (as I showed you in the section above).

A payment might start as a pain.001 customer credit transfer initiation, move across the banking network as a pacs.008 interbank credit transfer, get a status update through pacs.002, and later show up in account reporting through camt.054.

That is the important bit.

These messages are connected. Identifiers such as EndToEndId, original transaction references, and settlement references tie them together across the flow.

So if you treat each ISO 20022 message as a standalone XML file, you miss the bigger picture.

Here are the main ISO 20022 message families you will usually run into:

Message Family	Business Domain	Most Common Messages	Typical Use Case
pain	Payment Initiation	pain.001, pain.002, pain.007, pain.008	Customer credit transfers, direct debits, payment reversals, and payment status reports. This is what people often mean by ISO 20022 pain XML.
camt	Cash Management	camt.052, camt.053, camt.054, camt.056	Account reports, bank-to-customer statements, debit/credit notifications, and cancellation requests.
pacs	Payments Clearing and Settlement	pacs.002, pacs.003, pacs.008, pacs.009	Interbank payment status, direct debits, customer credit transfers, and financial institution credit transfers.
sese	Securities Settlement	sese.023, sese.024, sese.025, sese.026	Securities settlement instructions, confirmations, allegements, and status messages.
acmt	Account Management	acmt.001, acmt.002, acmt.003	Account opening, account details confirmation, and account modification.
tsmt	Trade Services Management	tsmt.001 through tsmt.055	Trade finance workflows, including matching, baseline, and trade services processes.
fxtr	Foreign Exchange	fxtr.008, fxtr.014, fxtr.015	FX trade status notifications, trade instructions, and trade instruction amendments.

With these in mind, what you should know next is that the ISO 20022 Repository and the ISO 20022 Messages Archive give you access to any of the raw materials for the message families:

• message definitions,
• message sets,
• documentation,
• and XSD downloads.

So if you check this material on the ISO 20022 Repository, you will find the XML messages used in business areas such as Account Management, Cash Management, Payments Clearing and Settlement, Payments Initiation, and Foreign Exchange Trade.

So, is the ISO 20022 standard useful and valuable for you and your team? Yes, without a doubt.

Is it simple to use? Not really.

For data engineering, each family brings its own structure.

A pain.001 payment initiation message does not look like a camt.053 bank statement. And a securities settlement message won’t behave like an FX trade notification.

Different families mean different nesting patterns, repeating groups, parent-child relationships, and target table designs.

And a lot of headaches if you try to manually convert each message family to a database across your ISO 20022 workflows.

So yes, ISO 20022 is a valuable standard. But it is not one single XML shape.

And that is where manual parsing and converting start to get ugly.

In the next section, I’ll show you exactly how these XML and XSD messages look, so that you get a glimpse of the workload involved in parsing and analysing them one by one.

The Structure of an ISO 20022 XML Message

So far, we have talked about ISO 20022 message types. Now let’s look at the XML’s structure itself.

Every ISO 20022 XML message is defined by an XSD. XSD stands for XML Schema Definition.

Think of the XML as the actual payment message, and the XSD as the rulebook for that message:

• The XML contains the data: payment IDs, amounts, parties, accounts, dates, and references.
• The XSD defines whether that data is structurally valid: which elements are allowed, which are required, which can repeat, what data types they must use, and in what order they must appear.

That matters because before you can safely parse ISO 20022 XML into database tables, you need to know the structure you are parsing. The XSD gives you that structure.

Next, I’ll show you two examples from the ISO 20022 payment lifecycle introduced earlier:

• The pain.001.001.09 message starts the payment from the customer side.
• The pacs.008.001.09 message carries the same payment between banks.

The useful part is that some fields, such as EndToEndId, can be carried from one message to the next.

That makes the payment easier to trace throughout the payment lifecycle.

If you stick with me, in the next few subsections, I’ll show you how EndToEndId is used in practise.

Downloading the pain.001.001.09 XSD

Before examining the XML example, I’ll first show where to find and download the corresponding XSD.

The pain.001.001.09 XSD can be downloaded from the ISO 20022 Messages Archive.

In the screenshot below, the ISO 20022 message catalogue is filtered for pain.001.001.09.

The result appears if you search for CustomerCreditTransferInitiationV09 and under Payments Initiation V10.

Example 1: pain.001.001.09 XML message

After downloading the XSD as shown in the previous section, you can use it as a reference for the XML message structure.

The following is a simplified pain.001.001.09 XML example:

At a high level, the structure looks like this:

The Group Header (GrpHdr) describes the file.

The Payment Information block (PmtInf) describes the payment batch.

The Credit Transfer Transaction Information block (CdtTrfTxInf) contains the actual payment.

That is where you find the amount, currency, payment reference, debtor, creditor, account details, and remittance text.

As I told you before, the most important element is the EndToEndId. In this example, the value is INV-984533-2026-04 and is located under CdtTrfTxInf.

That value can (and will) travel with the payment as it moves through subsequent messages in the flow (see Example 2 below).

Example 2: pacs.008.001.09 XML message

The pain.001 message shows the customer-to-bank instruction.

The pacs.008 message is used in the next step, which is the bank-to-bank message used to move the same payment forward.

Here is a simplified pacs.008.001.09 example:

At a high level, the pacs.008.001.09 message has the following structure:

This looks similar to the pain.001 message. But it is not the same shape.

The pain.001 message has a PmtInf block because it is a customer payment initiation file.

The pacs.008 message does not use the same structure. It focuses on interbank credit transfers.

That is one of the first things data engineers (like you) will notice with ISO 20022 XML.

One single business payment can include different XML message types.

Those message types can share important identifiers, but their XML structures are different.

And in case you didn’t notice, the EndToEndId is under CdtTrfTxInf with the value of INV-984533-2026-04.

Other Messages in the Payment Lifecycle

The two examples above show the first two steps from the workflow we saw earlier:

• pain.001 starts the payment from the customer side.
• pacs.008 moves the same payment between banks.

But the payment lifecycle does not stop there. After the payment is sent, other ISO 20022 messages can appear:

• pacs.002 is commonly used to report payment status.
• camt.054 is used later on the account side.

It notifies the customer about debit or credit entries on the account.

So the workflow looks like this:

I won’t include XML snippets for pacs.002 and camt.054 in this section and the blog post.

But it is important for you to take away that ISO 20022 messages are connected. They are not just isolated XML files.

Why does all this matter for databases?

These examples are small. Real ISO 20022 XML files can be much larger and more complex.

They can include many payments, many repeating blocks, optional fields, nested parties, addresses, agents, account details, and references.

That is fine for XML. It is not fine for a relational database.

A database wants tables. ISO 20022 gives you hierarchies.

Before you can analyse the data with SQL, you need to convert the XML structure into tables, columns, and relationships.

That is where the conversion problem starts. Let’s dive into ISO 20022 XML conversion to Relational tables in my next section.

Why Converting ISO 20022 XML to Relational Tables Is Challenging

Loading an ISO 20022 XML file into a database is not the hard part.

Many modern database platforms can store raw XML. Snowflake, for example, can ingest XML into a semi-structured column and let you query it later.

That sounds useful.

And it is, up to a point.

But storing ISO 20022 XML is not the same as converting ISO 20022 XML to relational tables.

A database wants rows and columns. ISO 20022 gives you a financial message hierarchy.

That mismatch is where the work begins.

Next, let me walk you through the full list of challenges that you will face in a ISO 20022 to SQL project.

Version fragmentation

The first challenge is version fragmentation.

As I showed you in the previous sections, a pain.001.001.09 message does not use the same XSD as pacs.008.001.09.

The same applies across other ISO 20022 message types. A bank, payment processor, or financial institution may receive multiple versions from different counterparties simultaneously.

That creates a simple but painful problem.

If your parsing logic is hard-coded for one version, it will break when another version arrives:

• A field may move.
• A structure may change.
• A rule may be different.
• An optional element may suddenly become important.

That is why ISO 20022 XML & XSD handling matters. You are not just parsing XML tags. You are working with formal message definitions that can vary by version.

Deeply nested structures

The second challenge is the structure itself.

In the previous section, I showed you a pain.001.001.09 XML message.

Even that small example already had several levels:

That is the friendly version:

• One payment.
• One payment information block.
• One credit transfer transaction.
• A few fields that are easy enough to follow.

But even here, the structure is already hierarchical. The amount is not neatly arranged in a column.

It is under CdtTrfTxInf > Amt > InstdAmt. The currency is not a separate element. It is an attribute of InstdAmt. The debtor account is under DbtrAcct > Id > IBAN. The remittance text is under RmtInf > Ustrd.

That is perfectly reasonable for an ISO 20022 payment message.

And real ISO 20022 XML can be much more deeply nested than this example.

So the problem is not just “XML has tags.”

The problem is that ISO 20022 XML uses nested financial business objects, which do not map directly to a single flat SQL table.

As I showed in my XML converter tool comparison post, most converters cannot automatically interpret nested XML structures.

They cannot reliably decide which block should become the parent table, which repeating block should become the child table, or which keys should link the two.

So, before you can analyse ISO 20022 data with SQL, and if you’re not using a dedicated XML to SQL converter, you need to turn the ISO 20022 data model into a relational model.

That means tables. And relationships. And repeatable conversion logic.

Not just “load the XML and hope for the best.”

In my figure below, you can see how the XML hierarchical tree structure of a pain.001.001.03 message (left side) can be translated into a relational schema (right side) with Primary Keys (PKs) and Foreign Keys (FKs).

Repeating groups and table design

Repeating groups are where manual conversion gets especially messy.

A single pain.001 payment initiation file with 500 credit transfer transactions, each with 30+ sub-fields, already contains 15,000+ data points in one XML file.

A standard SQL INSERT statement cannot consume that directly.

You first need to flatten the hierarchy. But if you flatten everything into one giant table, you risk duplication, cartesian products, and useless reporting tables that nobody wants to maintain.

The better approach is usually to create separate but connected tables.

For the simplified pain.001.001.09 example above, that could mean tables such as:

• message_header
• payment_information
• credit_transfer_transaction
• party
• account
• remittance_information

That structure is much more useful for analytics.

But designing it manually for every ISO 20022 message type is not exactly a relaxing afternoon.

Manual coding burden

Most teams start with custom code.

Usually Python. Sometimes Java, C#, or even XSLT (rarely nowadays).

That can work for a narrow use case.

If you only need to parse one message type, one version, from one counterparty, and into one target database, custom code may be sufficient.

The trouble starts when the scope grows:

• You need custom logic for each source structure.
• You need mappings for each target schema.
• You need tests for every version.
• You need someone who understands both ISO 20022 and the target database model.
• You need maintenance every time a schema changes.

This is how a small XML parsing script turns into a long-term engineering liability.

Scale

The final challenge is scale.

Large financial institutions do not process five ISO 20022 messages on a laptop.

They may process thousands or millions of payment, clearing, settlement, and account reporting messages per day.

At that point, manual or semi-automated conversion does not scale well.

The question is no longer:

“Can I parse this one XML file?”

The question becomes:

“Can I process ISO 20022 messages reliably across message families, schema versions, counterparties, and downstream analytics requirements?”

Which involves a series of pain points:

• Manual parsers break when ISO 20022 message versions change.
• Hard-coded XPath logic becomes difficult to test, debug, and maintain.
• Generic XML flattening can destroy parent-child relationships.
• Repeating payment blocks can easily produce cartesian products if handled badly.
• Schema drift creates rework whenever a new XSD version or counterparty variation appears.
• Missing source-to-target mappings make audits and governance more difficult.
• No lineage means analysts cannot easily trace a SQL column back to the original XML element.
• Large message volumes expose the limits of desktop scripts and traditional parsers.
• Manual conversion projects often grow from a quick parser into a long-term maintenance burden.

And this is why converting ISO 20022 XML to relational tables needs more than a generic XML parser.

That means your conversion process must:

It needs a repeatable and scalable way to read the XML and XSD, generate the relational model, and keep that model under control as schemas change.

• derive tables, columns, keys, and relationships from the ISO 20022 structure,
• preserve parent-child relationships across nested payment objects,
• generate source-to-target mappings and lineage,
• detect schema changes and support schema evolution,
• keep track of versions, metadata, and conversion rules,
• and scale beyond a few test files on a laptop.

If those capabilities are missing from your workflow, you are not really converting ISO 20022 XML to a database.

You are just moving the mess from one format into another.

Converting ISO 20022 XML to a Relational Database

So, how do you actually convert ISO 20022 XML to a relational database?

There are three main approaches:

1. Load the XML into a database such as Snowflake, and query it with native XML functions.
2. Write custom parsing and XML conversion code in Python, Java, or C#.
3. Use a dedicated XML conversion tool that automates the process for you.

All three can work.

In short, the right choice depends on how many ISO 20022 message types you need to process, how stable your schemas are, how quickly you need the data, and whether this is a one-off project or a production pipeline.

If you want the long version, I’ll walk you through the options next.

Option 1: Load ISO 20022 XML to database and query it natively

Modern databases can store XML as semi-structured data. For example, Snowflake can store XML in columns using the VARIANT type.

That means you can load ISO 20022 XML into an SQL database first, and then query it using native XML functions, FLATTEN, and lateral joins.

This is useful if your first goal is inspection.

You can load the raw XML, explore the structure, check values, and test how your pain.001 or pacs.008 messages behave inside Snowflake.

For small XML files and simple structures, this can be enough.

With this option, you don’t need:

• A separate conversion tool.
• An external parsing script.
• A target relational model upfront.

That is the upside.

However, while most modern databases can store the XML, but it does not automatically turn a nested ISO 20022 message into a clean relational schema.

This means that you or other downstream users will need to decide at some point:

• which XML blocks become tables,
• which elements become columns,
• how repeating groups are handled,
• how parent-child relationships are preserved,
• and how schema versions are managed over time.

In practice, the conversion usually happens in one of two places: either inside the database, managed by you and your team, or further downstream, when users access the data.

In the downstream approach, the XML is first loaded into the database in its original form. The schema and mapping are then applied only when the data is queried.

These are the steps to the process:

So yes, databases like Snowflake and Databricks can ingest ISO 20022 XML.

But loading raw XML is not the same as converting ISO 20022 XML to SQL tables.

Once the XML becomes deeply nested, the database parsing and handling functions become harder to use.

And when you start handling multiple ISO 20022 message types, your SQL can quickly become difficult to read, test, and maintain.

This approach is best when:

• The XML files are small or moderately simple,
• The structure is stable (very rare),
• The number of message types is limited,
• and your team has strong SQL and XML skills.

It is less suitable when you need to process ISO 20022 XML at scale across multiple message families, versions, and counterparties.

Option 2: Convert ISO 20022 XML with custom code

The second option is custom code.

This usually means Python, but it can also mean Java or C#, depending on your stack.

With Python, for example, you might use libraries such as lxml or ElementTree to parse the ISO 20022 XML, extract the fields you care about, and write the output into relational tables.

The basic flow looks like this:

• Step 1: Analyse your source XML and XSD files.
• Step 2: Define your target Database Target Schema.
• Step 3: Manually map your source XML to the target database rows and columns.
• Step 4: Write code to load the XML into the SQL tables according to the mapping from Step 3.
• Step 5: Run the code to insert data into the database (hopefully it succeeds and you won’t need to go back to steps 2, 3, and 4).
• Step 6: Query with SQL.

Of course, for each of the six steps I gave you above, there’s a ton of manual work underneath for you and your colleagues.

The manual code approach gives you flexibility and control. But it also brings challenges.

Because once you build the logic yourself, you own it.

If you write a parser for pain.001.001.09, that parser is usually tied to that message type and that version.

Then someone sends you pain.001.001.03.

Or pacs.008.001.09. Or camt.053.

Or the same message type, but with different optional branches populated.

Now the code needs to change.

Again.

For a narrow project, this is manageable. For a production ISO 20022 ingestion pipeline, costs quickly become high.

The real cost is not writing the first parser. The real cost is maintaining it.

You need to maintain mappings, tests, schema assumptions, validation rules, error handling, table definitions, and version-specific logic.

And this is before your downstream users ask for a new field that was buried three levels deeper than the original mapping covered.

Custom code is best when:

• You only need one or two message types,
• The ISO 20022 XML structure is stable,
• The target relational model is simple,
• and your team is comfortable maintaining the parser long term.

It is risky when:

• You process multiple ISO 20022 message families,
• You receive multiple schema versions,
• You need proper lineage and source-to-target mapping,
• or the pipeline is business-critical.

Option 3: Convert ISO 20022 XML automatically with Flexter

The third option is automated conversion with Flexter Enterprise.

This is the approach that makes sense when ISO 20022 XML conversion is not a one-off exercise.

Instead of manually writing parsing logic, Flexter Enterprise converts ISO 20022 XML to a relational database automatically for you.

That is the key difference.

Flexter does not just extract a few fields from XML.

It analyses the schema, understands the hierarchy, and creates a relational model with tables, columns, and relationships.

For the simplified pain.001.001.09 example earlier, that means the XML hierarchy can be converted into related tables, such as:

• message_header,
• payment_information,
• credit_transfer_transaction,
• party,
• account,
• Remittance_information.

In a real production project, the generated model can be much richer, as the full ISO 20022 XSD provides far more structure than the simplified example shown in this article.

The process with Flexter looks like this:

• Step 1: Provide the ISO 20022 XML and/or XSD file.
• Step 2: Flexter reads the ISO 20022 XML or XSD schema and generates the target relational schema without manual mapping.
• Step 3: Flexter automatically generates source-to-target mappings, entity-relationship diagrams, metadata and documentation.
• Step 4: Flexter processes the XML messages and loads the data into the generated tables.
• Step 5: You can then query your data with SQL.

That is the part that matters for data teams:

• You are not writing custom XPath logic for every branch.
• You are not manually designing tables for every repeating group.
• You are not rebuilding the pipeline every time a new schema version appears.

Flexter supports ISO 20022 loading to SQL Server, Snowflake, Databricks, Oracle, PostgreSQL, BigQuery, Redshift, and other JDBC-compatible databases.

So if your target is Snowflake or Databricks, you can still use them as the analytics platform.

The difference is that you load relational tables into your target database, rather than having every analyst query deeply nested XML directly.

This approach is best when:

• You need to convert ISO 20022 XML to a relational database at scale,
• You process multiple message types such as pain, pacs, and camt,
• You receive different schema versions,
• You need repeatable conversion logic,
• and you want queryable SQL tables without building a custom parser for every message.

Which approach should you choose?

I know you’re busy, so here’s the main takeaway:

• If you only want to inspect a single type of ISO 20022 XML file, native database XML support may be sufficient.
• If you have one stable message type and a strong engineering team, custom code may be acceptable.
• If you need production-ready ISO 20022 XML to database conversion across multiple message types, versions, and target databases, automation is usually the safer approach.

Approach	Best for	Main limitation
Load to database and use native XML functions	Fast ingestion and inspection of raw XML.	Still requires manual flattening and table design.
Custom code	Narrow, stable use cases with full control.	High maintenance burden as schemas and message types change.
Flexter Enterprise	Automated ISO 20022 XML to relational database conversion.	It is a commercial tool and has a license fee.

Analytics Use Cases for ISO 20022 Data in a Relational Database

If converting from ISO 20022 to a database is so challenging, why go through all this effort?

Because once ISO 20022 XML is converted into relational tables, it stops being a pile of nested financial messages and starts becoming usable data.

That is the whole point.

Surely, nobody converts ISO 20022 XML because they enjoy turning payment headers and transaction details into database tables.

You do it because you want to answer questions with SQL.

Keep reading to see when ISO 20022 XML to SQL conversion stops being optional and starts becoming necessary.

Payment analytics

The first use case is payment analytics.

Once pain.001 and pacs.008 messages are in relational tables; you can connect customer payment initiations with interbank settlement messages.

That means you can track a payment from the original instruction to the later bank-to-bank message.

For example, you can join on EndToEndId and compare timestamps:

Now you can detect delays, failed payments, settlement gaps, and SLA breaches.

Try doing that cleanly across raw XML files with XPath expressions. Exactly. Painful.

Fraud detection

ISO 20022 data also becomes useful for fraud and anomaly detection.

Once camt.053 bank statement data is stored in tables, you can use standard SQL aggregations and window functions to identify unusual behaviour.

For example:

• unusually high transaction volumes,
• repeated payments to the same creditor,
• sudden changes in payment corridors,
• outlier amounts by account,
• or suspicious transaction timing.

The important bit is that the data is no longer trapped inside nested XML.

You can query it, aggregate it, compare it, and feed it into downstream fraud models.

Regulatory reporting

Regulatory reporting is another obvious use case.

For example, if you need all cross-border payments over EUR 100,000 in Q1, you do not want to parse XML files one by one.

Here’s what such a query looks like:

That is the difference between reporting and suffering.

Once the data sits in relational tables, audit, reconciliation, and compliance reporting become ordinary database workloads.

Treasury analytics

Treasury teams also benefit from relational ISO 20022 data.

With camt.053 statement data in tables, you can reconcile cash positions daily, monitor balances across accounts, identify idle cash, and compare expected versus actual account movements.

That is hard to do when every account statement is still sitting as a separate XML document.

It becomes much easier when entries, balances, accounts, currencies, and transactions are queryable.

SEPA analytics

If you process SEPA direct debits, relational ISO 20022 data can also help with operational analysis.

For example, pain.008 direct debit data can be used to identify unpaid mandates, returned payments, debtor behaviour, recurring payment failures, and rejection patterns.

That kind of analysis needs relationships between mandates, debtors, accounts, payments, returns, and status messages.

In other words, it needs tables.

Frequently Asked Questions (FAQ)