Trust

Railflows is a secure RFQ workspace for institutional payment flows. The product is built around a small number of commitments to both buyers and providers. This page is the canonical statement of those commitments.

Confidentiality

Buyer identity, contact details and uploaded documents are never visible to providers by default. Providers see only an admin-curated, anonymized summary of an RFQ (segment, region group, volume band, payment types, corridors, settlement requirement, timeline, and a sanitized risk summary).

A provider can ask Railflows to forward a reveal request to the buyer. The buyer alone decides — per provider — whether to disclose their identity, and which (if any) of their uploaded documents to share. Buyer-controlled reveal is enforced server-side at every read path.

When a buyer approves a reveal, Railflows records a disclosure snapshot. The snapshot is immutable; later edits to the buyer's profile do not retroactively change what was disclosed.

Data visibility matrix

What each party sees about a buyer's RFQ, by default and after a reveal approval. Yes / No / If approved / Sanitised — applied at every server-side read path.

DATARAILFLOWS
ADMIN
MATCHED
PROVIDER
REVEALED
PROVIDER
Buyer legal nameIf approved
Contact name + emailIf approved
Uploaded documentsIf approved
Free-text pain pointSanitisedSanitised
Use case
Region group
Volume band
Payment types
Corridors (src → dst)
Settlement requirement
Timeline
Risk summarySanitisedSanitised
VisibleNot visibleIf approvedOnly if buyer approves revealSanitisedSanitised by admin curation

No funds, no KYB/KYC approval

Railflows does not hold, transmit, settle or process funds. Railflows helps companies source and benchmark regulated payment providers. All payment services are provided directly by licensed or otherwise authorised third-party providers.
Railflows may collect risk and onboarding-relevant information to assess provider fit. Railflows does not perform formal KYB/KYC approval and does not guarantee provider acceptance.

Commercial transparency

Railflows may earn revenue from provider participation, qualified introductions, buyer advisory work or future intelligence products. To keep the buyer-side comparison trustworthy:

Providers cannot buy ranking placement in buyer comparisons, and buyer identity or documents are never shared without buyer approval. Railflows comparisons are based on RFQ fit, including coverage, pricing, settlement, risk appetite, onboarding feasibility and integration needs.

Conflict controls (enforced)

  • Providers cannot buy fit score or ranking placement.
  • Buyer identity is never sold or disclosed without buyer approval.
  • Provider payments do not bypass admin review.
  • Provider payments do not bypass buyer reveal approval.
  • Buyer-facing comparison rows are based on RFQ fit and reviewed by Railflows.
  • Paid advisory is available for buyers who want deeper procurement support.

Security

  • Magic-link sign-in. Tokens are SHA-256 hashed at rest and single-use, with 15-minute expiry.
  • Sessions are HttpOnly and Secure cookies with a 14-day expiry, stored server-side in our database.
  • All sensitive read and write paths are guarded server-side. Provider download routes verify ownership, reveal approval, and document scope on every request.
  • Uploaded documents live in private object storage. There are no public URLs; downloads always go through an authenticated, audit-logged route.
  • Sensitive actions are audit-logged with actor, target, and timestamp.
  • Sign-in requests are rate-limited per email and per source IP (5 and 15 requests per rolling 10 minutes respectively). Responses are also constant-shape across known and unknown email addresses, so the endpoint cannot be used to enumerate users.

Scope of comparison scoring

Comparison fit scores are directional. The full disclaimer rendered next to every score:

Scores are Railflows' directional assessment based on available RFQ and provider response information. Final pricing, onboarding approval and commercial terms are subject to provider due diligence and agreement.

Last reviewed 2026-05-20 · Material changes are reflected on this page and in /changelog.