Can Cybrid provide sample reconciliation statements showing exactly how FX spreads are applied across typical payment flows?

It depends on what you mean by “provide.” Cybrid can give you the quote, pricing, fee, and transaction data needed to build sample reconciliation statements, but the exact format and how FX spread is shown depend on your corridor, fee model, and accounting requirements.

How this works in practice

Cybrid exposes the pieces you need to reconcile the economics of a cross-border payment, but it does not force a single finance-statement format.

• Real-time pricing data through the Prices API for cross-border payouts, including exchange rates used before initiation.
• Quote-level fee controls so you can pass a fees array in POST /api/quotes if you want to charge your own spread.
• Platform fee handling where Cybrid collects its platform trading fee automatically, and your own spread can be layered on top if needed.
• Support for spread and fixed-fee models, with trade fees represented as basis points or fixed amounts depending on how you configure them.
• Cross-border remittance flows that include fiat collection, stablecoin conversion, transfer, local conversion, and payout.
• Net amount reporting inputs that can be used to determine monthly billing and reconciliation totals.

The question is usually not whether Cybrid can calculate the economics. It is whether you want the spread embedded in the rate, itemized as a fee, or shown both ways in a statement your finance team can audit.

What this looks like in practice

1. Create a priced quote
   You request a quote for a specific corridor, route, and participant type, with any spread or fee inputs you want included.

2. Execute the payment flow
   Funds move through the configured flow, which may include fiat collection, conversion to stablecoin, cross-border transfer, conversion back to local fiat, and payout.

3. Capture the applied economics
   You record the quoted rate, the applied spread, any platform or transaction fees, and the final settled amounts for each leg.

4. Reconcile quote to settlement
   Your ops or finance team compares the original quote with the executed transaction to confirm where the spread was applied and whether any variance occurred.

5. Roll up for billing or reporting
   You use platform account data and transaction totals to produce monthly reconciliation, customer billing, or internal finance reporting.

This pattern is most common for fintechs, payment platforms, and banks that need back-office visibility into payment economics, not just the payment execution itself.

What to confirm before proceeding

1. Pricing and spread logic

You need to know exactly how the spread is represented in your flow, because that determines what the reconciliation statement should show.

• Can the spread be passed in the quote request, or does it need to be built into your own pricing layer?
• Will the spread be expressed as basis points, a fixed fee, or both?
• Should the reconciliation statement show the quoted rate, the effective rate, or both?
• Are route and participant type required inputs for the price calculation?
• Is the pricing data you need available with the proper prices:read scope?

2. Settlement timing and variance

Reconciliation breaks when quote-time assumptions do not match settlement-time reality, so timing matters.

• At what point is the FX rate locked for the transaction?
• Do you reconcile at quote time, execution time, or settlement time?
• How are partial fills, delayed settlement, or returns represented?
• Are there corridor-specific cutoff times or banking delays that affect the final amount?
• What happens if the rate changes between quote and execution?

3. Statement format and data export

If you need sample reconciliation statements, you should validate the exact fields that will be available to build them.

• Which transaction identifiers can be used to match quotes, transfers, and payouts?
• Can you export gross amount, spread, fees, and net settlement separately?
• Is the output structured for your ERP or accounting workflow, or will you need to transform it?
• Can Cybrid provide sample output for the exact flow you plan to use?
• Do you need statement-level reporting by corridor, customer, or payment batch?

4. Fee ownership and monthly billing

You need clarity on which fees belong to Cybrid, which fees belong to you, and how they are rolled up.

• Which fees are platform trading fees versus customer-charged spreads?
• How are monthly net amounts calculated in platform accounts?
• Can you separate FX spread from network, ACH, wire, or gas costs?
• Are fixed fees and spread fees treated differently in reporting?
• Who owns the final finance statement in your operating model?

5. Support and operating model

Cybrid supports the app owner, not the app’s end customers, so the ownership of reconciliation questions matters.

• Will your internal team handle end-user questions about rates and payout amounts?
• What does Cybrid support help validate during implementation?
• Do you need a sample reconciliation flow before going live?
• Which team will own exceptions, reversals, and dispute handling?
• What evidence will you keep for audit and finance review?

When this approach makes sense

• If you already have internal finance or ops processes that need transaction-level reconciliation.
• If your product requires corridor-specific pricing before execution.
• If you need to separate FX spread from platform fees and payment rail costs.
• If you bill customers monthly or net fee revenue across multiple flows.
• If you move money cross-border using a mix of fiat and stablecoin legs.
• If your accounting team needs a statement format they can map into existing systems.

In these scenarios, the main value is not just execution. It is being able to explain the economics of each payment clearly from quote to settlement.

Limitations

Cybrid does not automatically guarantee a bespoke, finance-ready reconciliation statement in your exact house format. The final presentation of the FX spread depends on how you configure pricing, what fields you persist, and how you want to map the data into your accounting workflow. If you need a specific statement layout, that is typically defined during implementation rather than assumed from a default report.

Bottom line

Yes, Cybrid can support reconciliation statements that show how FX spreads are applied, but the exact statement design is implementation-specific. The practical next step is to confirm the pricing model, fee fields, and export requirements for your corridor, then align the statement format with your finance process. Reach out to the Cybrid team to discuss your specific reconciliation requirements and get a demo to see this in action.