Matching mechanism

Introduction

The Reluna platform includes a robust matching mechanism designed to reconcile transactions received from your bank with those generated internally after order execution. This ensures your records remain accurate, your portfolio positions stay updated and your reconciliation process is both efficient and auditable.

Whether transactions are matched automatically by the platform or require manual review, the platform provides clear workflows to help you maintain clean, validated data across all portfolios.

This guide explains how matching works, when it happens automatically, when manual intervention is required and what you can edit before finalizing a match.

Key Terminologies

Term (A-Z)	Definition
Automatic Matching	A platform-triggered match based on preset rules and data alignment.
Bank Transaction	A transaction received from your custodian or bank.
Confirmed	Final status of a successfully matched bank transaction.
Manual Matching	A user-performed match when automatic matching is not possible.
Matching	The process of comparing and reconciling order transactions with bank transactions.
Omnibus Account	A collective account type holding transactions for multiple clients.
Order Transaction	A transaction created by the platform once you execute an order.
Standard Bank Account	A bank account directly linked to a specific client or portfolio.

👉 New to some terms? Check our full Platform Glossary for quick definitions.

Permission Requirements

To access the Transactions tab and perform actions such as matching or approving transactions, your profile must have the following permissions: View, Modify, Create, and Delete.

If you do not have the required access, please contact your Administrator.

Matching Scenarios Explained

Matching in the Reluna Platform helps align your internal records (order transactions) with external data (bank transactions). This ensures accurate reconciliation and smooth portfolio positions updates. The platform offers both automatic and manual matching mechanisms depending on data accuracy, integration setup and transaction completeness.

Visual Flow of Matching Logic in the Reluna Platform

How to Identify Bank vs. Order Transactions

Detailed information, here:

Before you start matching, it’s important to understand which transaction is from your bank and which is generated by the platform after an order is placed.

In Reluna, matching is always initiated from the bank transaction. Here’s how to differentiate them using filters in the Transactions tab:

Transaction Type	Where to Find on Platform?	Used For
Bank Transaction	Transactions tab > Filter `Status = Pending` + `Status Reason = Not Matched or Not Allocated orPending Confirmation`	Represents data received from the bank
Order Transaction	Transactions tab > Filter `Status = Active` + `Status Reason = Order`	Internal transaction generated after you execute an order in the platform

There are three main types of matching available on the platform:

1. Manual Matching

A process where you review unmatched bank transactions and manually link them to the correct order transactions. When it’s needed:

When the platform could not automatically match the transaction.
When there are data discrepancy, missing fields, etc.

How to Find These Transactions in the Platform

To locate and work with transactions that need to be matched, use these steps:

Go to Transactions tab (inside Portfolios or from Transactions).

Apply Filters:
- Status: Pending
- Status Reason: Not Matched

A list appears. Now, click on the Match button to match the bank transaction.

A pop-up window appears, compare the unmatched bank transaction with suggested order transactions.
By clicking on Potential Duplicates, the Result tab appears in the Matching section.

Matching Criteria Between System and Bank Transactions:

Platform Field	Matching Criteria	Note
Type	`type (system) = type (bank)`	Must match across all supported types: BUY, SELL, FX, FEE, INTEREST, PAYMENT, WITHDRAWAL, EXERCISE_OPTION, etc.
Bank Account ID	`bankAccountId (system) = bankAccountId (bank)`	The associated bank account must match in both system and bank transaction.
Status Reason	`statusReason = Order`	System transaction must be in the correct status to match.
Quantity	`quantity (system) = quantity (bank)`	Quantity must match exactly.
Multileg	`multileg (system) = multileg (bank)`	Multileg flag must match.
Order ID	`Order ID is not empty`	Used as part of the confirmation logic.
Gross Amount	`grossAmount ≈ grossAmount`	Can differ slightly (tolerance: up to 0.05%).
Instrument / ISIN	`instrumentRef = instrumentRef OR isin = isin`	At least one (Instrument Ref or ISIN) must match.
Value Date	`valueDate (system) = valueDate (bank)`	Required for certain types (e.g., Security Transfers).
Trade Time	`tradeTime (system) ≤ tradeTime (bank)` OR `tradeTime = tradeTime`	Matching logic varies by type — sometimes exact, sometimes less than or equal.
Price	`price (system) = price (bank)`	Price must match up to 3 decimal places.
Parent ID	`parentId is not null`	Required to match child transactions and confirm the parent correctly.

All active child transactions must be matched and confirmed for the parent transaction to be auto-confirmed.

Special Transaction Types & Matching Conditions:

Transaction Type(s)	Matching Criteria	Note
BUY + EXERCISE_OPTION	Price is not equal to 0	Only matches when price is non-zero.
EXERCISE_OPTION (price = 0) or EXPIRE_OPTION	Fallback match	Treated as special cases with no price or expiry logic.
SECURITY_TRANSFER	Type must match exactly	Ensures transaction type is identical.
SECURITY_TRANSFER	Value date must match	Timing must align for accurate settlement.
WITHDRAWAL / PAYMENT / FEE / INTEREST / TAX / MARGIN	Type must match	Ensures classification is correct.
WITHDRAWAL / PAYMENT / FEE / INTEREST / TAX / MARGIN	Value date must match	Matching is based on value date.
INVESTMENT / PAYMENT / CASH_TRANSFER / SECURITY_TRANSFER	Type must match	Standard type-based matching logic.
INCOME / BOND_REDEMPTION (full or partial)	Type must match	Treated under standard type-based matching.
FEE	Trade time must be earlier than or equal to bank trade time	Fee must post at or before the time seen on the bank side.
FX	Trade time must be exact match	FX trade time must align exactly.
FX	Price must match (up to 3 decimals)	Allows slight rounding differences but ensures close precision.

Now, check for mismatched fields/data, they will be highlighted in red.

Manually click on the red fields and correct them to align with the bank transaction.

Editable Fields During Manual Matching:

Platform Field	Description
Price	Price at which the instrument was bought or sold.
Quantity	Quantity of the instrument traded.
Trade Time	Time when the transaction was executed.
Value Date	Date when the value of the transaction is settled.
Value	The transaction’s value before fees or adjustments.
Gross Amount	Total transaction amount before fees or commissions.
Net Amount	Final transaction value after fees and charges.
Net Amount Portfolio Ccy	Net amount converted into the portfolio’s currency.

Once all details align, click on Match button, again.

The platform will:

Mark the bank transaction as Active with Confirmed status reason.
Deactivate the order transaction and mark it as Duplicate.

Portfolio positions are updated accordingly.

2. Automatic Matching

A background process where the platform automatically links bank transactions to matching order transactions. When it happens:

As the bank transaction is received.
All required fields match exactly (Instrument, bank account, type, quantity, etc.)

How It Works:

The platform scans for an exact match between a bank transaction and an active order transaction.
If a match is found:
- Order transaction status = Active
- Status Reason = Confirmed
If not an exact match:
- Order transaction status = Duplicate
- Status Reason = Deactivated

Portfolio positions are updated accordingly.

Use the "Not Matched" filter to track which transactions were not automatically matched.

3. Approving a Transaction Without an Order

Sometimes, a bank transaction may not have a related order transaction, especially if the order was placed outside the platform or if integration is not yet set up. In these cases, you don’t need to match the transaction. You simply approve it directly.

Use this when:

No order transaction exists on platform.
The transaction is legitimate and needs to be approvd, manually.

Always validate that the transaction is legitimate before approving.

How to Approve Without Matching

Locate the unmatched bank transaction with:
- Status: Pending
- Status Reason: Pending Confirmation
Click the Approve button next to the transaction.

There is no matching step in this case.

What Happens After Approval

The transaction is marked as Active.
The Status Reason is updated to Confirmed.
The transaction is finalized without needing to match to any order.

Matching Transactions for Omnibus Bank Accounts

If you are working with Omnibus bank accounts, the matching process is slightly different from standard bank accounts.

Unlike standard accounts, where each bank transaction matches one order. The Omnibus process involves grouped client-side transactions and the platform helps you reconcile them more efficiently in bulk.

The platform initiates matching automatically for Omnibus accounts when:

A bank transaction is received and is linked to an Omnibus bank account
There are related order transactions to the same Omnibus account, possibly across multiple clients or portfolios

What the Platform Does

Once a matching Omnibus bank transaction is detected:

The platform identifies all related order transactions under that Omnibus account.
In the Transactions tab, find the Omnibus-linked bank transaction with Not Matched status.

Click the Match button.

A window opens showing Potential Duplicates.

Click on a suggested transaction pair to review the details.
If there are mismatches (e.g., Quantity, Price, TradeTime), the fields will appear in red.

Fields Taken After Matching (Order > Bank Transaction):

Field on Platform	Updated During Matching	Description
Instrument	Yes	Taken from the linked order transaction.
Instrument Name	Yes	Derived from the matched instrument.
Bank Account	Validated	Must match the order's related bank account.
Type / Sub Type	Validated	Retained or matched, depending on transaction type logic.
Ccy / PF Ccy	Yes	Ensured to align with order and portfolio currencies.
Trade Time	Yes	Pulled from the order if not already filled. Editable if mismatch occurs.
Value Date	Yes	Aligned with order settlement date or manually adjusted. Editable if mismatch occurs.
Price	Yes	Taken from the order if relevant. Editable if mismatch occurs.
Quantity	Yes	Sourced from the order. Editable if mismatch occurs.
Commission	Yes (if applicable)	Populated if part of order’s fee logic.
Order	Yes	Direct reference to the matched order transaction.
Transaction Number	Yes	Updated for traceability (order or external ref).
Gross Amount	Yes	Calculated based on matched order values.
Net Amount	Yes	Adjusted if applicable.
Net Amount PF Ccy	Yes	Converted into portfolio currency if needed.
Accrued	Optional	Populated if interest-bearing instruments are involved.
Status	Yes	Automatically set to `Active`.
Status Description	Yes	Automatically set to `Confirmed`.
Error Description	Cleared	Cleared if error resolved after matching.
Matched (checkbox)	Yes	Ticked once matched.
Product ID	Yes (if linked)	Inherited from the matched order’s strategy/product.
Updated At / By	Platform	Logged by platform at the time of match.

Click on red fields to edit and correct the values as needed.

Once the values are aligned, click Match again to confirm.
Each transaction is updated with:
- Status = Active
- Status Reason = Confirmed

You do not need to manually select and match each client transaction under an Omnibus account, the platform handles this in bulk to save time and reduce risk of manual error.

Matching for Partially Filled Orders: Parent vs Child Transactions

When working with Partially Filled Orders, it's important to know what to match, especially if child transactions are involved.

What to Look For

Parent Order: Shows the overall order status and approved quantity.
Child Order Transactions Toggle: When enabled, this reveals individual execution legs.
Transactions: Will list all DEBIT/CREDIT entries created as part of the execution.

What You Should Match

Match the executed (filled) part of the Parent Order.
Here, child transactions are shown, you may choose to match those individually, especially when allocations or fills are split.
Click on Match to proceed.

Do not match the full approved quantity unless fully filled/submitted.

When to Match at Parent Level

If the platform does not split the order into separate child legs — i.e., all partial executions are reflected directly in the main transaction list, match at the parent level for the executed quantity.

When to Match at Child Level

If the order is broken down into child orders and you need to match each separately, based on execution quantity.

After successful matching, the transaction will appear with Status: Active and Status Reason: Confirmed, indicating that this leg of the partially filled order has been reconciled correctly.

Once this leg is matched:

The remaining quantity of the order stays open and can be executed later as needed
A new transaction leg will be generated for the next executed portion
You can repeat the matching process for each newly executed leg