BRidge Rulebook
Baseline operating rules for contracts, BOLs, inventory, RFQs, futures, settlement, disputes, and compliance controls.
1. Purpose and Operating Standard
BRidge is an auditable commodity contracting, logistics, inventory, RFQ, futures, settlement, and documentation platform for physical and financially-referenced commodity workflows. This Rulebook establishes the default operating rules for platform participation, contract creation, contract acquisition, Bills of Lading, inventory movement, price references, RFQs, futures listings, disputes, payouts, audit logs, and system-controlled legal/compliance gates.
2. Rule Hierarchy
Where multiple rules apply, BRidge applies the following hierarchy unless a written agreement states otherwise:
- Applicable law, sanctions, export controls, court orders, and regulatory requirements.
- Executed customer agreement, order form, or enterprise agreement.
- Product-specific rulebook, listing rule, futures rule, delivery rule, settlement rule, dispute rule, or force-majeure rule.
- This BRidge Rulebook.
- Operational instructions shown in the BRidge user interface or API documentation.
3. Participants
BRidge participants may include sellers, buyers, yards, mills, brokers, traders, carriers, administrators, compliance operators, API clients, and data-license users. Each participant must operate through an authorized account, tenant, organization, membership, role, permission set, or approved integration credential.
4. Identity, Organization, and Access Controls
- Each user must maintain accurate identity, organization, role, contact, and authorization information.
- BRidge may map aliases, display names, tenant slugs, account IDs, and organization keys to canonical identities.
- Users may not share credentials, bypass role controls, impersonate another party, or access contracts, BOLs, RFQs, data, documents, accounts, or ledgers outside their authorization.
- BRidge may suspend or restrict access when identity, authority, payment status, compliance status, or tenant context cannot be validated.
5. Products and Market Objects
BRidge may support spot contracts, forward contracts, RFQs, inventory-linked contracts, futures products, futures listings, benchmark-index references, physical delivery workflows, cash settlement workflows, broker workflows, and exchange/integration workflows.
Each product or listing may carry its own product code, material canonical identity, instrument code, reference symbol, unit, pricing unit, lot size, tick size, tenor, delivery region, settlement method, delivery method, dispute rules, force-majeure rules, freight rules, quality rules, and index-settlement rules.
6. Material Identity and Quality
BRidge may resolve raw material names into canonical materials, instrument codes, index symbols, quality bands, grade tolerances, vendor aliases, and product definitions. Where material identity cannot be resolved, BRidge may reject, hold, or route the activity for review.
7. Contract Formation
A BRidge contract may be formed, staged, matched, signed, dispatched, delivered, fulfilled, settled, cancelled, or disputed according to platform workflow and applicable product rules. Contract fields may include buyer, seller, tenant IDs, organization keys, material, canonical material, instrument code, reference symbol, weight, price, currency, pricing formula, status, delivery terms, settlement terms, and related evidence.
8. Open-Market and Directed Contracts
Open-market contracts may be visible to eligible buyers. Directed contracts may be visible only to the intended buyer, organization, tenant, or authorized role. The BRidge purchase or buy action is the acquisition event and may stamp canonical buyer ownership, update contract status, create or link a Bill of Lading, and write audit/event records.
9. Bills of Lading and Physical Movement
BOL workflows may include pickup scheduling, carrier identity, driver information, truck/VIN information, material, weight, price-per-unit, total value, origin/destination, customs/export fields where applicable, signatures, delivery proofs, weigh tickets, receipt postings, and delivery completion.
A BOL may not be issued, received, or completed where product rules prohibit physical delivery, settlement readiness is incomplete, required evidence is missing, or the transaction is blocked by compliance controls.
10. Inventory and Receipt Posting
Inventory movements may include adds, receipts, reserves, commits, releases, adjustments, transformations, or settlement postings. Inventory balances must be traceable to contract, BOL, receipt, evidence, material identity, tenant, and actor context where applicable.
11. Pricing, Indices, and Reference Data
BRidge may use internal indices, vendor quotes, public references, manually approved references, contract-derived prices, benchmark publications, and index snapshots. Pricing references are operational tools and may be subject to licensing, availability, confidence scoring, governance, latency, and correction rules.
Unless expressly licensed, users may not redistribute, resell, scrape, reverse engineer, publish, or externally commercialize BRidge indices, feeds, benchmark outputs, or derived data.
12. RFQs and Broker Workflows
RFQs may be posted, quoted, awarded, converted, cancelled, or expired according to permissions and product rules. Broker activity may include customer books, relationship records, contract claims, commissions, payout statements, communication templates, and role-specific entitlements.
13. Futures and Hedging Workflows
Futures products and listings may be created, listed, halted, expired, settled, or governed according to product rulebooks, listing rules, risk limits, collateral rules, account permissions, order-book controls, and settlement procedures.
Seller-created futures products or hedgeable instruments must use platform-approved productization rails, canonical material identity, lot standards, tenor definitions, pricing units, settlement rules, delivery rules, and risk controls.
The order book applies price-time priority; an order amendment that changes economic terms may reset that order's time priority. BRidge may support market, limit, and stop / stop-limit order types, and may conduct call-auction (uncrossing) price discovery and execution at a single volume-maximizing price in addition to continuous matching. Trading in a listing may be closed at its last trade date (LTD), after which open positions route to settlement or delivery per product rules.
14. Orders, Accounts, and Trading Controls
Trading workflows may require authorized accounts, linked account users, entitlements, account ownership checks, active listings, valid order parameters, sufficient risk capacity, price-band compliance, and idempotent submission behavior.
BRidge applies pre-trade risk controls that may include: portfolio initial-margin sufficiency computed on a scenario-scan (SPAN-style) basis, checked before an order is accepted and before a triggered stop order is injected; per-order maximum-quantity ("fat-finger") limits; position limits; price bands; entity-level and account-level self-match prevention; and trading-halt and kill-switch checks. An order that fails a hard pre-trade control may be rejected with a structured reject code.
15. Settlement, Payouts, and Reconciliation
Settlement may be physical, financial, index-based, contract-price-based, or otherwise defined by product rules. Payouts, payables, receivables, reconciliation records, ledger entries, and approval records may be held or modified based on contract status, dispute status, settlement readiness, payment rules, or administrative review.
For margined instruments, BRidge may collect and monitor initial margin and variation margin, revalue accounts intraday against the latest marks, and maintain a mutualized guaranty fund sized against a documented stress-scenario library (including a "cover the largest two members" / Cover-2 standard and reverse-stress analysis). Loss absorption in a member default may follow a defined default waterfall. BRidge may run periodic margin backtesting and scheduled reconciliation (including position cross-foot and ledger integrity checks) to validate risk parameters and detect drift.
Physical delivery execution is subject to product rules and may not be available for all instruments; where an instrument is cash-settled, no physical delivery obligation arises. No customer funds are moved by the platform except where money-movement has been expressly enabled and the applicable licensing, custody, and compliance requirements are satisfied.
16. Disputes and Evidence
Disputes may be opened for contracts, BOLs, payouts, invoices, receipts, shipments, or other supported objects. Evidence may include BOL PDFs, signatures, scale tickets, delivery photos, quality inspections, settlement measurements, communications, payout records, carrier records, and document-vault records.
BRidge may preserve dispute evidence, update audit records, freeze workflows, require additional documentation, or escalate disputes to administrators or authorized reviewers.
17. Export, Country, and Jurisdictional Controls
Export-control and country-restriction rules apply where configured or legally required. BRidge may require country-of-origin, destination country, port code, HS code, duty/tax values, end-use data, carrier information, and other jurisdictional evidence before allowing cross-border workflows.
18. Compliance, Membership, and Prohibited Conduct
Users may not use BRidge for unlawful activity, sanctions evasion, fraud, market manipulation, false documentation, credential sharing, data scraping, unauthorized data redistribution, abusive behavior, harassment, cyber abuse, payment evasion, or any conduct prohibited by the Terms, EULA, Acceptable Use Policy, or applicable law.
Participation in trading workflows may be conditioned on membership onboarding and a compliance gate that can require: identity verification (KYC), business-entity verification (KYB) against public registries, beneficial-ownership / ultimate-beneficial-owner (UBO) disclosure, sanctions screening, and acceptance of a membership agreement. Sanctions and business-verification checks are operated on a fail-closed basis — a member that is unscreened or unverified may be blocked from trading. Members may be assigned a member class (for example clearing, trading, or broker) with associated capital or eligibility standards; BRidge may suspend or restrict a member that is below its capital requirement or whose compliance status cannot be validated.
BRidge conducts market-integrity surveillance, which may include continuous wash-trade / self-match detection and spoofing / layering (cancel-rate) detection across the order books. Surveillance signals may result in review, alerts, holds, restrictions, or escalation.
19. Auditability, Idempotency, and Records
BRidge may require idempotency keys, request IDs, audit events, event hashes, document records, integration events, webhook signatures, job-run logs, and evidence trails for state-changing workflows. These controls support replay protection, duplicate prevention, traceability, dispute handling, and institutional-grade auditability.
High-stakes and state-changing actions may be recorded to a tamper-evident, hash-chained audit log that is sealed on a recurring (nightly) basis and periodically verified for integrity. BRidge may enforce role-based access control (RBAC) for staff and operator functions and dual-control (maker-checker) approval for sensitive operations, such that a single operator cannot both initiate and approve a controlled action.
20. System Availability and Operational Controls
BRidge may apply rate limits, maintenance windows, safety holds, kill switches, product halts, listing halts, account locks, tenant restrictions, API limits, or manual interventions to protect system integrity, users, market operation, or legal compliance. Halt and kill-switch controls may operate at market-wide, per-symbol (circuit-breaker), per-listing, and per-member scope; certain of these controls are fail-closed, meaning trading is rejected where the control's status cannot be confirmed.
21. Corrections and Reversals
BRidge may correct obvious errors, duplicate events, malformed records, failed integrations, orphaned records, bad mappings, stale references, invalid calculations, and system-generated inconsistencies. Corrections should preserve an audit trail where technically feasible.
22. Amendments
BRidge may update this Rulebook by publishing a new version, updating the effective date, and retaining prior versions where required by contract, policy, or operational need. Continued use after an update may constitute acceptance of the updated Rulebook.