Disclosure model

Default — anonymised summary

When a buyer's RFQ is approved for matching, Railflows builds an anonymised summary from the structured fields and shows only that to matched providers.

What the matched provider sees

• Use case (e.g. marketplace cross-border payouts)
• Region group (e.g. EU-headquartered, paying out globally)
• Volume band (banded, not exact)
• Currency pairs and corridors
• Payment type preferences
• Settlement requirement
• Timeline
• Risk summary — sanitised by admin curation

What the matched provider does not see

• Buyer's legal name or trading name
• Buyer's contact name or email
• Uploaded documents
• Buyer's free-text pain point (only the sanitised version)
• Exact volume figures

Reveal requested

When a provider wants to engage commercially, they ask Railflows to forward a reveal request to the buyer. The provider writes a short message explaining why they want to engage; Railflows forwards it to the buyer with the provider's identity attached.

The buyer can respond with approve, decline, or no response. Each option is audit-logged. There is no automatic timeout that defaults to approval — silence stays as silence.

What the buyer sees

• Provider's legal identity
• Provider's licence basis and supervisor
• Provider's coverage profile (already public on Railflows)
• Provider's free-text reveal message
• Per-document selector: which uploaded documents to share if approving

Buyer approves (or declines)

Buyer approval is granular. The buyer ticks which fields to disclose and which documents to share. They can approve identity but withhold contact details. They can approve everything except a specific document. They can decline entirely.

The decision is enforced server-side at every read path. A provider with an approved reveal sees only the fields the buyer specifically approved. There is no server-side fallback to "show everything" in any code path.

Disclosure snapshot

When the buyer approves a reveal, Railflows captures an immutable disclosure snapshot — a frozen record of exactly what was disclosed at the moment of approval. Later edits to the buyer's profile, RFQ content, or uploaded documents do not retroactively change what was already disclosed.

The snapshot is what the provider sees from that point on. If the buyer later wants to grant additional access (a new document, the contact phone number, an updated risk summary), they raise a second reveal action that produces a second snapshot. There is no "edit the original disclosure" path.

Snapshots are retained for the life of the engagement and are available to both parties as audit evidence. The buyer can revoke future access, but the snapshot documenting what was disclosed remains.

Every transition is logged

Each state change writes to the audit log with actor, target, action, and timestamp. The audit log is the source of truth for who saw what and when — available to both buyer and Railflows admin.

Related pages