BridgTime Whitepaper
Numbers shown are demo data. Features are not final and may change.
- Project : BridgTime — RWA × AI Settlement Attestation Network
- Category : RWA × AI, B2B SaaS, On-chain Attestation/Oracle
- Primary Users : Merchants/Suppliers; LFPs; PG/Acquirers; Banks; ERP/ISV; Auditors
- Token (Planned) : BRTM — Utility
BridgTime — Connecting time to value for everyone.
Executive Summary
BridgTime is a blockchain (RWA × AI) project aiming to build a B2B SaaS that verifies settlement-pending sales relayed by payment gateways (PGs) with AI, records those verification facts on-chain as a single standardized Receivable Verification Attestation (RVA), and enables licensed finance partners to decide—independently and quickly—on pre-payment or early-settlement so merchants can receive their proceeds sooner.
Why use it?
• Merchants supplying large retail channels (e.g., convenience stores, general distribution, pharma) often face 60–90 day settlement lags that tie up working capital.
• BridgTime verifies “settlement-pending sales” delivered by PGs using AI and publishes a standardized, machine-readable RVA. Licensed finance partners can then make their own pre-funding decisions under their internal policies and applicable licenses/regulations.
• Result: merchants may bring cash forward with a small discount; finance partners can target rational margins on verified short-dated cash flows; PGs can more easily attract and retain merchants via a standardized assistive program. (Finance partners set terms independently under their own rules/licenses; BridgTime does not solicit, broker, arrange, or advise—information provision only.)
How we use RWA
The RWA concerned is “settlement-pending sales” that are expected to convert to cash shortly.
• We do not move that value on-chain. Instead, we record a standardized RVA capturing the verification fact—existence, status, and provenance—so it is durable and reproducible.
• The blockchain does not trigger movement of funds; it serves as an immutable ledger for verification, transparency, and traceability.
• An RVA does not constitute any right or claim (ownership, economic interest, participation, security interest, repurchase right, receivable claim). It is “verification-fact metadata” usable as reference material for accounting/tax/regulatory assessments.
• Issuance or status changes of an RVA do not trigger payment, settlement, assignment, collateralization, or the creation of any rights.
Who can participate (examples)
• Merchants/Suppliers: suppliers to convenience & super chains; FMCG/food & beverage/household-goods manufacturers & wholesalers; pharma/med-device/health-supplement distribution; franchise HQs & franchisees (F&B, cafés, bakeries, etc.); TV-shopping & e-commerce vendors; marketplace sellers with delayed settlements; logistics-linked B2B sellers (including categories with frequent chargeback/dispute patterns).
• Licensed Finance Partners (LFPs): pre-payment/factoring/short-term credit providers; financial institutions; specialized corporate/P2P lenders (as permitted).
• Data/Payments Partners: PGs/van/acquirers; settlement banks (settlement events/statements integration).
• Systems/ISV Partners: ERP/POS/inventory/accounting SaaS; reporting & risk-console ISVs.
• Audit/Supervisory & Risk Stakeholders: internal audit/risk; reg-tech; external audit (read-only access).
(The above are example scenarios for using BridgTime’s B2B SaaS. They are not solicitations, offers, or brokerage. Availability depends on jurisdictional/regulatory compliance and specific partner agreements.)
Merchants & Suppliers
Pharma / Health Distribution
Franchise HQs & Franchisees
E-commerce & TV-Shopping Vendors
Marketplace Sellers (Delayed)
Logistics-linked B2B Sellers
Licensed Finance Partners (LFP)
PGs & Acquirers
Settlement Banks
ERP / POS / Inventory SaaS
Reporting & Risk ISVs
Audit & Supervisory (Read-only)
Note
This page reflects plans and intent. Features, timelines, partnerships, and policies may be modified, deferred, or discontinued based on technical, security, regulatory, and market conditions. Implementation details and eligibility vary by partner agreements and applicable law.
Problem Definition & User Needs
Long settlement cycles and high inventory needs worsen the cash conversion cycle
• In large retail and pharma distribution channels, settlements typically arrive well after the sale.
• Channels often require inventory coverage for multiple months, including safety stock.
• The result: even when sales grow, cash takes a long time to arrive, tying up a large share of working capital.
Pressure in practice (illustrative)
• A small or mid-sized merchant with steady monthly sales can see a large portion locked as settlement-pending receivables for weeks to months.
• Inventory coverage across channels further increases the cash parked in stock.
• The combined burden can delay production, marketing, and product launches, or force reliance on expensive short-term borrowing.
Limits of existing alternatives
• Banks / ABL / factoring: lengthy and complex reviews; documentation heavy; collateral and recovery structures to explain; partial advances are common; disbursements can be slow and staggered; higher rates and fees are typical for smaller or newer businesses; repeated, channel-specific submissions raise internal costs.
• Internal cash cycling: delaying supplier payments or cutting promotions strains relationships; trimming buffer stock risks stockouts and penalties.
Operational risks and inefficiencies
• Fragmented data: distributors, PGs, ERPs, and banks all use different formats and cadences.
• Reconciliation friction: automated matching between sales, settlements, and deposits often fails, leading to manual work and errors.
• Fraud and anomaly exposure: fabricated sales, unusual off-hour spikes, refunds and offsets expand error bands in settlement forecasts.
• Decision latency: credit checks and risk reviews are manual and non-standardized, increasing lead times.
User needs (merchants and finance institutions)
• A standardized verification workflow: document collection → AI triage → reviewer oversight → attestation issuance.
• A machine-readable trust signal that can be referenced instantly, capturing when, amount, authenticity, provenance, and signatures.
• Auditable logs with timestamps, signers, and status-change history, while minimizing personal data exposure.
• Automated reconciliation by channel and counterparty to shorten underwriting and disbursement lead times.
What we aim to do
• Standardize and verify channel/PG settlement data and issue/update the results as on-chain attestations (RVA).
• Provide a B2B SaaS layer that helps licensed finance partners (LFPs) decide on prepayment faster and more safely.
• We do not change PG/card settlement rules, cycles, or fee structures. Verification, attestation, and recording are provided outside those systems.
Key components (design intent)
1) RVA (Receivable Verification Attestation) — on-chain attestation
• Consider issuing/updating a machine-readable object that includes receivable authenticity/status/rating, source signatures, timestamps, and document hash (CID).
• Format under review: EAS/EIP-712 signature–based, or a non-transferable (SBT) NFT.
• On-chain, write only hash/rating/status/signature/time to minimize exposure of personal or commercial secrets.
2) AI Risk Engine (off-chain) — verification automation
• Implement/integrate document OCR, sales time-series anomaly detection, and risk scoring.
• Aim to provide explainable alerts (e.g., “overnight cluster sales, refund spikes”).
3) Oracle Layer — settlement event synchronization
• Collect PG/bank settlement confirmations (webhooks/signatures) and batch-commit to chain via an m-of-n consensus gateway.
• Include replay-protection nonces, signature verification, and SLA monitoring.
4) Validator Network — quality assurance (under review)
• Consider BRTM staking (bonding) requirements for validators/oracle participants; apply slashing for false or delayed reports.
• Cross-audit/sample re-verification to ensure quality.
5) Dashboard & API — visibility & reconciliation
• Auditable logs for enterprises/LFPs, RVA lookup, assisted auto-reconciliation, portfolio metrics, and developer APIs.
6) Governance & Timelock — operating parameter management (optional)
• Public scope, rating rules, oracle set, fee schedule, and slashing table under vote + 48–72h timelock (under review).
Prepayment connection (incl. rate preferences)
• Merchants may enter preferred rate ranges as preference information; this is not an offer or firm term and has no legal effect.
• LFPs independently determine whether/size/rate of prepayment based on RVA signals and their own policies and regulatory compliance. All prepayment/collection/terms/underwriting follow off-chain contracts unrelated to BridgTime; BridgTime does not solicit, broker, arrange, or advise.
• Phrases like “full advance” describe possibilities only and are not guarantees. Access may be restricted or blocked if jurisdictional/regulatory requirements are not met.
Blockchain-based differentiation (intent)
| Category | Legacy | BridgTime (intended) |
|---|---|---|
| Data provenance | Mixed captures / CSVs / emails | Signed webhooks + on-chain RVA (machine-readable) |
| Integrity & source proofs | Manual inference; hard to audit | m-of-n signatures + immutable log (chain timestamp) |
| PII exposure | Originals circulate | Only hash / status on-chain; originals encrypted off-chain |
| Underwriting speed | Repetitive submissions; manual recon | Standardized schema → automated recon / instant reference |
| Incentive alignment | Unclear quality incentives | Staking & slashing (rules via governance) |
| Change control | Opaque changes / rollbacks | Governance + timelock (under consideration) |
Data & privacy principles (intent)
• On-chain: record only hash/rating/status/signatures (minimize exposure of personal and commercial secrets).
• Off-chain: encrypted storage of originals, access logs, and reviewed deletion/retention policies.
• Audit viewer: restricted-role sample original cross-check (under review).
Expected effects (assumptions; not guaranteed)
• Shorter underwriting lead times, higher auto-reconciliation rates, lower delinquency/fraud, and improved settlement forecast accuracy are targeted outcomes.
Boundaries (what we don’t intend to do)
• No intent to raise funds from or distribute returns to the public/retail.
• Will not request changes to PG settlement rules/cycles.
• No custody or deposit-taking function; prepayment and collections are executed by LFPs via off-chain contracts.