Edit rail · CustomerInboundACHReturnNSF (two-leg)

← back to Rails
ⓘ Reference

A Rail is a money-movement contract — one well-known way value flows between roles. ACH origination, wire settlement, intra-day pool balancing, fee debits all live as Rails. Every transaction must match a rail by (rail_name, source_role, destination_role).

Required: name (unique identifier; chains, templates, and limit schedules all reference rails by this name — it doubles as the L1 matview's rail_name column value). Endpoint roles (source_role / destination_role) are edited on the rail itself after it's created — required for the validator to accept the rail as connected.

Two-leg rail requires:

Both legs auto-balance to expected_net by the template's completion deadline (or on the rail's own firing when standalone).

Where this sits

Open full diagram →
Identity
Unique rail identifier; referenced by chains + templates.
Free-form prose; markdown OK.
Topology
  • CustomerDDA
Role of the account the debit leg posts to. Add one or more roles (union: any matches at posting time). Required on TwoLegRail.
  • ExternalCounterparty
Role of the account the credit leg posts to. Add one or more roles (union: any matches at posting time). Required on TwoLegRail.
Origin
ExternalForcePosted / InternalInitiated. See SPEC's Origin table.
Per-leg override. Blank ⇒ use the rail-level Origin for both legs.
Per-leg override. Blank ⇒ use the rail-level Origin for both legs.
Conservation
L1 Conservation contract for standalone firings (typically 0). Leave blank when this rail is only used as a TransferTemplate leg — the template owns the bundle's ExpectedNet.
Activity / cadence
true ⇒ rail fires on cadence (sweep / batch) and the bundles_activity / cadence fields apply. false ⇒ fires per-Transfer.
For aggregating rails (e.g. intraday-2h / daily-eod).
  • No bundles activity selected yet — type below to add.
For aggregating rails only. Names the rails / templates whose Transactions this rail bundles. Type below to add; drag to reorder; × removes.
Metadata
  • original_external_reference
  • return_reason_code
  • customer_id
Metadata key names this rail's transactions carry. Pick from the L2-wide list or type a new one (e.g. ach_trace_number, wire_imad).
Posted requirements
One per line. Rail-specific fields the L1 PostedRequirements view requires beyond the auto-derived TransferKey + chain-Required fields (see derived.posted_requirements_for).
Aging
ISO 8601 duration (e.g. PT24H, PT4H, P1D). L1 Pending Aging flags any pending Transaction older than this. Empty ⇒ no watch.
ISO 8601 duration (e.g. P3D). L1 Unbundled Aging flags any Transaction older than this without a bundling parent. Empty ⇒ no watch.
Soft bounds
Optional soft bound on per-firing abs(amount). Format: `min, max` (e.g. `5.00, 500.00`). Generator samples log-uniformly within this range, producing realistic demo amounts. Validator V1a-c rejects min≥max, non-positive values, and aggregating rails. Empty ⇒ falls back to per-kind lognormal heuristic.
Optional soft bound on how many times this rail fires per period. Format: `min, max` (defaults to per business day, e.g. `50, 500`) OR `period: min, max` where period is business_day | pay_period | week | month (e.g. `month: 80, 120`). Generator samples uniformly per period. Validator W1a-c rejects min>max, negatives, and aggregating rails. Empty ⇒ falls back to per-kind heuristic.
Cancel
In Use