How Numeral automates reconciliation for payment companies

At Numeral, we aim to provide fintechs and banks with the best solution to build and operate payment products on top of their partner banks, payment schemes, and other payment providers, at scale.

While the ability to send and receive payments through connected partner banks is the core of our platform, this is only part of the solution. Building and operating payment products while complying with regulatory requirements involves various additional processes, including reconciliations.

Reconciliations are critical to any company, even more so for those whose payments are core to their products.

They are how fintechs assign payments to customer accounts. They enable them to close their books. They are the basis of regulatory reports they must be able to produce to regulators. They ensure fintechs operate compliant safeguarding workflows and can track the allocation of customer funds at any point in time.

Reconciliations also play a key role in payment products' end-user experience. In many use cases, payments such as merchant payouts or the second legs of cross-border payments are conditional to reconciling a pay-in or other collected payment. Reconciliation delays directly impact the payouts.

As we’ve just added the support of card and alternative payment methods (APM) reconciliations to our reconciliation capabilities, we’re taking this opportunity to unpack how Numeral supports fintechs with reconciliations for all their payment use cases.

Native integrations with banks, acquirers, and APM providers

The first step of any reconciliation is to retrieve the necessary payment and transaction data from banks, internal systems, and third-party systems. However, this is a challenging task: banks, acquirers, and APM providers share transaction and payment data in different file formats.

Each file often contains information about multiple payments or transactions. Identifying individual payments and transactions and their attributes (amount, date, etc.) in these files across all banks, card acquirers, and APM providers is complex.

This makes integrating with a new bank or acquirer resource-intensive.

In this section, we detail how Numeral solves this problem, enabling customers to accelerate the launch of new payment methods and geographies without breaking reconciliation workflows.

Automatically retrieving bank transaction data

Our bank integrations connect with banks’ cash management systems to send payment orders and retrieve payment status updates and incoming payments. But they also retrieve account statement files that contain account balances and transactions posted on these accounts.

These files are parsed to retrieve individual transactions with all their attributes which are then normalised to create the corresponding transaction objects in Numeral.

Even if the format of account statement files changes from one bank to another or if the transactions are not located or represented in the same way from one bank to another, Numeral will automatically extract the correct information and store it in a normalised way.

Details of a transaction in the Numeral dashboard

Automatically retrieving payment data

Payments can be created in fintechs’ own systems or in third-party systems. In this section, we detail how this data is imported and normalised in Numeral for each type of payment.

Sent payments

An outgoing payment initiated through Numeral will have been created in Numeral as a "payment_order" (documentation).

Fintechs use Numeral to automate their payments at scale, so they will automatically initiate payments through Numeral from their internal systems. Internal systems such as core banking systems (CBS), ERP, treasury management systems (TMS), or others are connected to Numeral via API or dedicated integrations.

Some outgoing payments made from bank accounts connected to Numeral can still be initiated via another method, for instance, via the bank’s web banking interface. In such cases, customers can create the corresponding "expected_payment" in Numeral manually or via API.

Received payments

The way to manage received payments is different whether a Numeral customer is a bank corporate customer or an indirect participant, as well as for bank, card and APM payments.

For corporate customers:

• Expected arriving payments are created in Numeral as "expected_payment", usually via API from customers’ internal systems.

• Unexpected payments are usually created after the fact, as an "expected_payment" by the customer when a credit transaction that does not correspond to a previously sent direct debit is posted on the connected account.

• Returns are automatically created by Numeral as returns when Numeral identifies a return in a notification file from the bank

• Note that a transaction sent to a virtual IBAN or account number registered in Numeral is automatically attributed to the counterparty linked to the virtual IBAN

For indirect participants:

• Payments arriving on their corporate accounts are managed the same way as for corporate customers.

• Incoming payments arriving on their indirect participant account, or “processing account”, are automatically identified by Numeral from financial institution to financial institution pacs files themselves automatically retrieved from the sponsor bank. Once identified, they are automatically created in Numeral as "incoming_payments".

• Returns are automatically created by Numeral as “returns” when Numeral identifies a return in a notification file from the bank

Card and APM payments:

• Card or alternative payment method charges, refunds or chargebacks are created in Numeral as "payment_captures", usually via API.

Automatically retrieving data from card acquirers and APM providers

Today, we are announcing the end-to-end automation of card payments and APM reconciliation.

Payments made via card or alternative payment method (PayPal, BNPL…) are often settled via bulk payments on fintechs’ bank accounts.

To reconcile individual payments with these bulk settlements, we need the data that links individual payments with these bulk settlements. This data needs to be retrieved from the card acquirer or the APM provider.

Through native integrations with these providers, Numeral automatically:

• Retrieves the files of API responses containing the required data from the provider

• Parses the files or responses to extract the required data

• Normalises the data across providers

• Enriches previously created "payment_captures" with the data that will link them to bulk settlements and individual entries in the settlement report

For card payments, Numeral is also able to identify and enrich payment captures with:

• Fees: acquirer and other parts of the card payments value chain take fees on each card payment to remunerate themselves. These fees are withheld by the acquirer from the bulk settlement or debited separately via a debit settlement comprising only fees.

• Chargebacks: it is a card payment sent back to the cardholder when the cardholder disputes said payment for fraud or other reasons. Chargebacks are withheld by the acquirer from the bulk settlement or debited separately via a debit settlement comprising only chargebacks.

• Refunds: refunds are card payments sent back to the cardholder when the merchant proactively decides to refund the cardholder. They are withheld by the acquirer from the bulk settlement or debited separately via a debit settlement comprising only refunds.

Automating all reconciliations with a rule-based engine

Reconciliation processes that are not fully automated break when payment operations scale.

Numeral includes a built-in rule-based reconciliation engine that automatically reconciles bank, card and APM payments with transactions, including fees, chargebacks and returns. This enables customers to maintain compliance and regulators’ trust at scale.

The reconciliation engine creates reconciliations by matching payments and bank account transactions leveraging previously retrieved, parsed and normalised bank data, internal data and, when required, third-party data.

Supported data models

Not all reconciliations consist of matching one payment with one transaction. Numeral supports one-to-one, one-to-many and many-to-many reconciliations: 

• One-to-one reconciliations consist of reconciling 1 payment with 1 transaction. For instance, 1 payment sent is reconciled with the corresponding 1 debit transaction on the connected account.

• One-to-many reconciliations consist of reconciling 1 payment with multiple transactions or multiple payments with 1 transaction. They are important in the case of card settlements when multiple individual card payments are paid via 1 bulk card settlement, leading to 1 credit transaction on the connected account. Another use case is when 1 expected payment is actually paid via 2 bank payments, leading to 2 credit transactions on the connected account.

• Many-to-many reconciliations consist of reconciling multiple payments with multiple transactions. An example of such a scenario is when multiple individual card payments are paid via 1 bulk card settlement, leading to 1 credit transaction on the connected account, but the fees corresponding to these individual card payments are debited from the connected account via 1 “negative” bulk settlement, leading to 1 debit transaction on the connected account.

How rule-based reconciliations work

Numeral automatically reconciles payments and transactions based on more than 12 default payments and transaction criteria plus custom criteria recorded in metadata, combined into rules. Criteria include the amount, direction (debit or credit), date, reference, technical IDs, and payment capture-specific data such as authorisation ID and any metadata.

Criteria can be combined to create a reconciliation rule. Reconciliation rules are ranked. The engine goes through reconciliation rules based on their rank. The engine automatically stops when a reconciliation is created.

Each of our customers might pass their own custom unique IDs as payment references, automatically enrich their payments and transactions recorded in Numeral with additional data useful for the reconciliation process or require their specific reconciliation rules for various reasons.

Numeral allows customers to leverage their custom data and automatically reconcile according to their rules by adding custom rules to their reconciliation engine.

Built-in support for any bank, acquirer, and APM provider

In addition to native integrations to retrieve the required data, Numeral comes with default reconciliation rules for each connected bank and acquirer, allowing high reconciliation rates without further configuration, regardless of the connected banks and acquirers

Providing finance and operations teams with the right tools

Identifying, investigating and resolving reconciliation errors is extremely time-consuming with inadequate tools.

Numeral gives customers the tools to monitor automatically created reconciliations and identify unreconciled payments and transactions, as well as the tools to override the reconciliation engine if necessary.

From the Numeral dashboard, finance and operations teams can autonomously access payments and transactions on connected accounts with their reconciliation status.

List of transactions retrieved from different connected accounts displayed in Numeral dashboard

List of payments sent from and received in different connected accounts displayed in Numeral dashboard

They can also access the reconciliation details of each payment and view the linked transaction(s). And vice-versa.

After identifying an issue, finance and operations teams can quickly resolve it by cancelling a reconciliation if they deem said reconciliation incorrect and manually reconciling unreconciled payments and transactions.

Leverage reconciliations in real-time

In the case of payment or payment-based products, reconciliations are often critical steps in various workflows that have a direct impact on the customer experience.

For instance: Payfacs and BNPL providers send merchant payouts after validating the funds corresponding to a collected payment have effectively been received through reconciliation. Neobanks and other fintechs holding customer accounts update their user balances based on reconciled sent and received payments.

As such, reconciliations need to be easily usable in third-party systems such as core banking systems, in real-time. 

Numeral enables its customers to do so by sending events via webhooks in the following cases:

• When a payment, expected payment or payment capture has been reconciled or partially reconciled

• When a transaction has been reconciled or partially reconciled

• When a reconciliation itself has been created

As discussed in this article, reconciliations are also used for internal accounting and regulatory reporting processes. It is, therefore, critical for customers to be able to import reconciliations and their underlying data into third-party systems such as ERP, accounting software, and TMS.

Numeral enables customers to do so by retrieving via API or exporting as CSV through the dashboard:

• Payments, expected payments a payment captures and their reconciliation status and amount

• Transactions and their reconciliation status and amount

• Reconciliations themselves, as well as the ID of the linked payments and transactions

Rely on a future-proof infrastructure for everything payments

With increasing regulatory scrutiny and heightened competition on payment cost, speed and coverage, fintechs’ ability to grow and launch new products while maintaining compliance at scale and keeping low operational overhead is getting critical.

We aim to enable fintechs to do so with reduced complexity. We believe that combining a comprehensive payment platform with reconciliation capabilities purpose-built for payments provides our customers with the best infrastructure to grow and innovate with confidence.

Leading fintech companies like Alma, Spendesk, and Swile already rely on Numeral to automate their payment operations at scale. Including their reconciliations.

For more information, contact us.