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

It depends on the format you want. Cybrid can provide the underlying pricing, trade, transfer, and fee data needed to build sample reconciliation statements that show FX spreads across typical payment flows, but Cybrid does not provide downloadable bank statements via the dashboard or API.

The practical answer: how this actually works

Cybrid gives you the transaction-level inputs you need to reconstruct FX economics, but the statement itself is usually built in your own reporting or ledger layer. The useful question is usually not whether Cybrid hands you a preformatted statement, but whether Cybrid exposes enough pricing, fee, trade, and transfer detail for your finance system to reconcile cleanly.

• Cybrid’s Prices API can provide real-time exchange rates for cross-border payouts, with the required prices:read scope.
• You can pass your own spread or markup in the fees array on POST /api/quotes.
• Cybrid collects its platform trading fee automatically.
• GET /api/trades gives you trade activity you can use to reconcile conversion legs.
• GET /api/transfers gives you transfer data, with filters such as account_guid, customer_guid, state, and side.
• Trade fees can be modeled as spread fees in basis points or fixed fees in base units, depending on how you configure them.
• Cybrid does not provide downloadable bank statements via dashboard or API, so any statement-style report is assembled from your own data model.

The practical takeaway is that Cybrid can support the reconciliation logic, but your team decides how the spread is displayed, booked, and reported.

What this looks like in practice

1. Create the FX quote
   You capture the exchange rate, any spread you want to apply, and the fee treatment for the payment.

2. Execute the payment flow
   A typical backend-only remittance path may move through fiat collection, fiat-to-stablecoin conversion, cross-border transfer, stablecoin-to-local-fiat conversion, and local payout.

3. Pull the source records
   Your system uses trade and transfer records to capture gross amounts, fee amounts, timestamps, and execution states.

4. Reconcile the spread
   You compare the quoted rate to the executed rate or fee line items, then calculate how the spread affected the net payout.

5. Generate your statement view
   Your reporting layer formats the data into the exact reconciliation statement, ledger export, or finance report your team needs.

This pattern is common for fintechs, payment platforms, and banks that want transaction-level control without turning Cybrid into their reporting system of record.

What to confirm before proceeding

1. Data model and identifiers

You need to know whether your reporting layer can join the right events together reliably.

• Which objects expose the quote, trade, transfer, and fee data you need?
• What unique IDs should you store to link quote → trade → transfer?
• Do the records include timestamps, states, amounts, and asset/currency pairs?
• Can you filter the data by account, customer, date range, and corridor?

2. FX spread treatment

You need to confirm exactly where the spread lives in the flow.

• Is the spread represented as an explicit fee, embedded in the rate, or both?
• Can you separate your markup from Cybrid’s platform trading fee?
• Are spread fees expressed in basis points or fixed base units in your implementation?
• How are rate changes, re-quotes, or partial executions handled in reconciliation?

3. Ledger and settlement timing

You need to define the booking point before you try to build a statement.

• Which event should trigger ledger posting: quote creation, trade execution, or transfer completion?
• At what point is the FX rate considered locked for finance reporting?
• How are failures, reversals, and cancellations represented?
• Do you need separate postings for fiat in, conversion, stablecoin transfer, and local payout?

4. Statement format and operational ownership

You need to decide what the final output should look like and who owns it.

• Do you need a per-transaction statement, a daily summary, or a corridor-level report?
• What columns does your finance team expect for FX, fees, spread, and net settlement?
• Will the output live in CSV, JSON, ERP import format, or an internal dashboard?
• Who on your team owns the customer or finance support process when a payment needs explanation?

When this approach makes sense

• if you already have an internal ledger or finance reporting layer
• if your product needs to show FX markup separately from the base rate
• if you need auditability across quote, trade, and transfer events
• if you reconcile multi-leg payment flows across fiat and stablecoin
• if you operate multiple corridors with different pricing rules
• if your team wants transaction-level data, not a prebuilt bank-statement UI

In these cases, Cybrid gives you the infrastructure data you need, and your own systems handle the statement format and presentation.

Limitations

Cybrid does not provide downloadable bank statements via the dashboard or API, so you should not expect a ready-made reconciliation PDF or ledger report out of the box. If you need a statement that shows exactly how FX spreads were applied, you build that in your own reporting layer from Cybrid’s transaction-level data, fees, and pricing inputs. The exact output depends on how you configure quotes, spreads, and payment routing.

Bottom line

Yes for building sample reconciliation statements from Cybrid data, no for a built-in bank-statement output. If you want to show exactly how FX spreads flowed through quote, trade, fee, and payout legs, Cybrid gives you the underlying records and pricing inputs; your team owns the statement format and ledger presentation. Map your flow with the Cybrid team to confirm integration fit.