@@ -63,6 +63,16 @@ risk_pct: 0.01
 # subscribed tier — the choice is declared, never assumed, because the venue's server-side
 # default silently fails for keys without the subscription). Omitting the section entirely
 # selects Coinbase, byte-compatibly with every other profile.
+#
+# CASH-ACCOUNT POSTURE (#372): this venue is traded CASH-ONLY — margin borrowing is riba
+# and the cash posture keeps the account outside the PDT rule's $25k margin-account
+# threshold — and it is ENFORCED, not a knob here: every broker build reads the venue's own
+# account classification (/v2/account's `multiplier`) and refuses a margin-postured account
+# (fail-closed on an unreadable one). Note the venue's default cuts against the posture: a
+# fresh paper account's $100k equity classifies it reg T MARGIN (multiplier 2), so the
+# account's max margin multiplier must be set to 1 in the Alpaca dashboard before the first
+# cycle will run. See the runbook's "Account posture" section for the full split of what is
+# enforced in code versus what the operator must keep verified.
 broker:
   name: alpaca
   endpoint: paper
 
@@ -622,34 +622,84 @@ considered, and it lapses weekly like every deployment's attestation.
 
 ### T+1 settlement × daily cadence
 
-US equities settle T+1: sale proceeds become spendable the next business day. On a **daily**
-cadence this is immaterial for entries — the next entry attempt is at least a day after the
-previous buy, by which time it has settled (a weekend makes it longer, never shorter).
-**Exits are never T+1-blocked**: a SELL produces cash rather than spending it, and the engine
-never needs to spend sale proceeds within a cycle. The documented cash-crunch case: on a cash
-account you cannot spend *unsettled* proceeds, so an operator manually redeploying same-day
-sale proceeds (outside the engine, which cycles daily) is the one way to meet the constraint
-— and it is an operator act, not an engine one. The paper profile's synthetic cash does not
-model settlement at all; that honesty is on record for any future live consideration.
+US equities settle T+1: sale proceeds become spendable the next business day. Settlement is
+**venue-side** — nothing keel can enforce about *when* the venue settles, so this section is
+the documented half of a split whose enforced half already exists:
+
+- **What keel enforces/surfaces**: the balances read reports the spendable figure honestly —
+  `available` is the account's buying power clamped at cash, so unsettled T+1 proceeds show
+  up as the gap between `available` and `total` rather than as spendable money (FR-6, the
+  #562 balance work) — and **rail 13** (the spend rail) vetoes any BUY whose notional
+  exceeds the reported available quote balance, failing closed when the balance is
+  unreadable. The engine cannot spend what it cannot see.
+- **What the operator must respect**: cadence choices that would re-spend unsettled
+  proceeds. On the profile's **daily** cadence the constraint is met by construction — the
+  next entry attempt is at least a day after the previous buy, by which time it has settled
+  (a weekend makes it longer, never shorter), and **exits are never T+1-blocked**: a SELL
+  produces cash rather than spending it. The one documented cash-crunch case is an operator
+  manually redeploying same-day sale proceeds *outside* the engine — an operator act, not an
+  engine one. The same `interval_sec` that makes this true also scales the feed-staleness
+  window (B1), so any future tighter equities cadence must re-answer settlement and
+  staleness together; a sub-daily cadence is not merely a staleness question.
+
+The paper profile's synthetic cash does not model settlement at all; that honesty is on
+record for any future live consideration.
 
 ### Account posture: cash only — never margin — and the PDT rule
 
-The equities profile runs against a **cash account, never a margin account**. Margin
+The equities profile runs against a **cash-equivalent posture, never borrowed funds**. Margin
 borrowing is a loan that charges interest — *riba* — so the posture is categorical, not a
-preference; a cash account also sidesteps the pattern day trader (PDT) rule's $25,000
-minimum-equity requirement, which applies to **margin** accounts only. The PDT rule: FINRA
-flags a **margin** account as a pattern day trader when it executes four or more day trades
-within five business days, and such an account then needs $25,000 of equity to keep day
-trading. A cash account running keel's daily cadence is not that pattern — the rule does not
-bind cash accounts, and in any case keel evaluates a session's bar once and holds overnight
-by construction, so it does not day-trade in the first place; settled-cash funding is what
-makes entries wait for settlement, and that interplay is the T+1 section above (not repeated
-here).
-
-Enforcement in code — the config refusing a margin posture where the venue reports one — is
-issue **#372**'s scope; this runbook carries the operator-facing half now: **create and keep
-the Alpaca account a cash account** (the paper account is one by default), and treat any
-offer to "upgrade" to margin as a posture violation to decline, not a capability to use.
+preference; **no-borrowing is the posture's whole claim, and it sidesteps nothing on PDT.**
+The PDT rule: FINRA flags a **margin** account as a pattern day trader when it executes four
+or more day trades within five business days, and such an account then needs $25,000 of
+equity to keep day trading — the rule binds margin accounts, and a true cash account would be
+exempt, but **Alpaca offers no true cash accounts**: per Alpaca staff on the cash-account
+option (forum.alpaca.markets/t/dan-wheres-the-cash-only-account-option/18353), "currently all
+Alpaca accounts are margin accounts" — at `max_margin_multiplier=1` "the account remains a
+margin account" and "pattern day trading rules apply". What actually keeps keel clear of PDT
+is the **cadence**: keel evaluates a session's bar once and holds overnight by construction,
+so it does not day-trade in the first place; settled-cash funding is what makes entries wait
+for settlement, and that interplay is the T+1 settlement section above (not repeated here).
+
+**Enforced in code since #372, not just documented.** Alpaca has no `account_type` field;
+`/v2/account`'s `multiplier` is the venue's account margin classification, and it is as
+cash as the venue gets: Alpaca opens every account as margin and offers no true cash
+designation — multiplier **1** is the cash-equivalent posture (buying power equals cash,
+shorts refused), **2** reg T margin, **4** PDT day-trading margin. At broker build — every
+command that constructs one: the agent cycle, `fetch`, `monitor`, the order paths —
+`AlpacaAdapter.verify_cash_account` reads that classification and **refuses** a margin
+postured account (`CashAccountRequired`, naming riba, the honest PDT note — the posture
+buys no exemption; the cadence is the PDT safety — and the fix), and refuses fail-closed
+when the classification cannot be read: silence is not
+consent to borrow. The engine never sees a broker on a margin account.
+
+**The operator's half — set the multiplier, and expect to.** The venue's *default* for any
+account with $2,000 or more equity is reg T margin (multiplier 2) — and a fresh Alpaca
+paper account carries $100,000 of paper equity, so the default classification is MARGIN:
+the first cycle against an untouched paper account refuses until the setting is changed.
+Set the account's **max margin multiplier to 1** (the dashboard's trading-configuration
+setting; at 1 the venue refuses orders beyond available cash and blocks shorts), keep it
+there, and treat any offer to "upgrade" to margin as a posture violation to decline, not a
+capability to use. **Confirm the classification took** before moving on: re-run
+`keel assets holdings` — a cash classification builds the broker and lists balances, a
+margin one still refuses — or read `GET /v2/account`'s `multiplier` directly, which must
+answer `1`. If the refusal persists with the setting saved, that is a question for Alpaca
+support, not something to work around: the setting you changed lives on the venue's
+account-configurations object (`max_margin_multiplier`, `PATCH /v2/account/configurations`)
+while the classification keel reads lives on the account object itself, and the venue
+implies but does not document the linkage between the two.
+
+The posture is one system with the rest of the engine's constraints — where each piece
+lives:
+
+| Constraint | Where it lives | Why there |
+| --- | --- | --- |
+| No margin borrowing (riba) | **Enforced in code**: `verify_cash_account` at broker build refuses any multiplier ≠ 1, fail-closed on unreadable | The venue reports the classification; refusing at build covers every path before one sees a broker |
+| Cash-only declared | `BrokerCapabilities.cash_only` — every adapter declares it, `keel brokers list` shows "cash only" | The port's declaration seam: vocabulary for the day an adapter announces a borrowing path |
+| Long-only, no shorting | **Enforced in code**, pre-existing: `Setup.direction` is `Literal["long"]` (a short entry cannot be constructed), exits only close held longs, rails 18/19 refuse non-spot shapes in every mode | Not new in #372 — cited so the posture reads as one system, not three |
+| T+1 settlement churn | **Documented** (the section above): settlement is venue-side; keel surfaces the spendable figure and rail 13 spends only that | Nothing keel can enforce about when the venue settles |
+| PDT $25k threshold | **Documented** (this section): keel's CADENCE — one evaluation per session bar, holds overnight by construction — is the PDT safety; the posture claims no exemption (at multiplier 1 the account remains a margin account under PDT rules) | The safety is the cadence, not the posture; there is no separate rule to enforce |
+| Stock lending / cash sweep OFF | **Operator-verified** (the section below) | No order is placed; no rail can see account settings |
 
 ### Operator-verified opt-outs (Alpaca account level)
 
 
@@ -174,6 +174,14 @@ def _build_broker(config: Config, *, timeout: int | None = None) -> Any:
     the real (network-free at construction) Alpaca and Coinbase classes by
     `tests/test_paper_equities_profile.py`.
 
+    **The alpaca branch verifies the account posture before returning** (#372): one
+    `verify_cash_account()` read of the venue's own account classification, refusing a
+    margin-postured account (and failing closed on an unreadable one) so no engine path
+    ever sees a broker on a venue posture keel does not trade -- cash only, no margin
+    borrowing (riba), which is the posture's whole claim: it sidesteps nothing on PDT
+    (keel's PDT safety is the cadence, not the posture). The refusal names the posture
+    and the fix; the runbook's "Account posture" section is the operator-facing half.
+
     `timeout` (seconds) is optional and defaults to `None` -- the SDK's own default (no
     timeout), matching every existing caller (the agent/executor broker path) exactly.
     Callers that cannot tolerate a hung network call pass an explicit bound.
@@ -233,6 +241,17 @@ def _build_broker(config: Config, *, timeout: int | None = None) -> Any:
     )
     # `adapter_cls` IS the class the entry point registered -- constructed through discovery
     # (not a direct import) so the installed adapter, not a hard dependency, is what runs.
-    return adapter_cls(
+    broker = adapter_cls(
         transport, endpoint=config.broker.endpoint, data_feed=config.broker.data_feed
     )
+    # Cash-account posture (#372, PRD §5): the one venue-state check this seam makes. The
+    # adapter reads the venue's own account classification and refuses a margin-postured
+    # account (`CashAccountRequired`, a RuntimeError like this function's other refusals),
+    # fail-closed on a classification it cannot read. Refusing HERE -- rather than at order
+    # time -- is what makes it a posture and not a rail: guards are broker-less by design,
+    # and a per-order raise could fire on an exit path, where a refusal can trap a
+    # position. Every command that builds a broker (agent cycle, fetch, monitor, the order
+    # paths) inherits it; one extra `/v2/account` read per build sits far inside FR-11's
+    # rate budget at the daily equities cadence.
+    broker.verify_cash_account()
+    return broker
@@ -80,6 +80,10 @@ class BrokerInfo:
     #: Whether the venue CLOSES (`capabilities().session_bound`): session-bound
     #: venues render with a market clock; the rest are 24/7.
     session_bound: bool
+    #: Whether the adapter spends settled cash only (`capabilities().cash_only`, #372)
+    #: -- the declared funding posture. Every first-party adapter declares True; a False
+    #: row would be an adapter announcing a borrowing path the engine can refuse at load.
+    cash_only: bool
     quote_currencies: tuple[str, ...]
     asset_classes: tuple[str, ...]
     supported_orders: tuple[str, ...]
@@ -173,6 +177,7 @@ def list_installed_brokers() -> list[BrokerInfo]:
                     venue=capabilities.venue,
                     deployment=WIRED if name in WIRED_FOR_DEPLOYMENT else OPTIONAL,
                     session_bound=bool(capabilities.session_bound),
+                    cash_only=bool(capabilities.cash_only),
                     quote_currencies=tuple(sorted(capabilities.quote_currencies)),
                     asset_classes=tuple(sorted(capabilities.asset_classes)),
                     supported_orders=tuple(sorted(capabilities.supported_orders)),
@@ -193,6 +198,7 @@ def list_installed_brokers() -> list[BrokerInfo]:
                     venue="",
                     deployment=WIRED if name in WIRED_FOR_DEPLOYMENT else OPTIONAL,
                     session_bound=False,
+                    cash_only=False,
                     quote_currencies=(),
                     asset_classes=(),
                     supported_orders=(),
@@ -218,12 +224,18 @@ def list_installed_brokers() -> list[BrokerInfo]:
 
 
 def capability_facts(info: BrokerInfo) -> str:
-    """The row's capability facts as one " · "-joined phrase -- the SHARED wording the CLI
-    prints and the Venues browser wraps, so the two front-ends cannot drift. PURE."""
+    """The row's capability facts as one " · "-joined phrase -- the wording
+    `render_brokers_lines` prints for `keel brokers list`. (The console Venues browser
+    that once wrapped this same phrase is gone -- #541 deleted the console layer -- so
+    "the shared wording two front-ends render" describes nothing today; the phrase stays
+    a single PURE function so the next front-end inherits it rather than re-deriving
+    it.)"""
     hours = "session-bound (opens and closes)" if info.session_bound else "24/7"
+    funding = "cash only" if info.cash_only else "MARGIN-CAPABLE"
     facts = [
         info.deployment,
         hours,
+        funding,
         f"quotes {'/'.join(info.quote_currencies)}",
         f"asset classes {'/'.join(info.asset_classes)}",
         f"preview {info.preview}",
@@ -238,9 +250,9 @@ def capability_facts(info: BrokerInfo) -> str:
 
 def adapter_error_block(info: BrokerInfo) -> list[str]:
     """The honest block a raising adapter's row renders as: its name and installed
-    version, then the construction error wrapped to the 78-column budget -- the SAME
-    wording both front-ends render (the one-phrase rule `capability_facts` keeps), so a
-    broken adapter reads identically everywhere. PURE, and deliberately states NO
+    version, then the construction error wrapped to the 78-column budget -- spelled
+    once here so a broken adapter reads the same everywhere (the one-phrase discipline
+    `capability_facts` keeps). PURE, and deliberately states NO
     capability fact: an adapter that could not be constructed has declared nothing."""
     return [
         f"{info.name} ({info.package_version or 'unknown version'}) -- unavailable",
 
@@ -1663,6 +1663,11 @@ def _venue_payload(info: Any) -> dict[str, Any]:
         "package_version": info.package_version or "",
         "preview": info.preview,
         "session_bound": flag(info.session_bound, on="session-bound", off="stateless"),
+        # The #372 funding posture, beside the session one: "cash only" is the declaration
+        # every first-party adapter makes, and the off word is the loud one for the day a
+        # row ever carries it -- the venueCard's funding cell mirrors `capability_facts`'s
+        # "MARGIN-CAPABLE" declaration without inheriting its shout.
+        "cash_only": flag(info.cash_only, on="cash only", off="margin-capable"),
         "supports_fee_summary": flag(
             info.supports_fee_summary, on="fee summary", off="no fee summary"
         ),
 
@@ -1700,6 +1700,7 @@ function venueCard(info) {
     gridCard([
       kv("preview", plain(info.preview)),
       kv("session", info.session_bound),
+      kv("funding", info.cash_only),
       kv("fee summary", info.supports_fee_summary),
       kv("package version", plain(info.package_version) || "—"),
     ]),
 
@@ -14,6 +14,23 @@ construction path to a trading host (no constructor parameter accepts a host URL
 there is no configuration path from a paper credential to
 `https://api.alpaca.markets`, by construction.
 
+## Cash-account posture (#372)
+
+The cash half of the scope is **enforced, not just declared**. Alpaca has no
+`account_type` field; `/v2/account`'s `multiplier` is the venue's account margin
+classification (`1` cash-equivalent — buying power equals cash, shorts refused; `2` reg T
+margin; `4` PDT day-trading margin), and the venue's *default* for any account over
+$2,000 of equity — a $100k paper account included — is margin. Every broker build calls
+`AlpacaAdapter.verify_cash_account()`: multiplier 1 passes, anything else raises
+`CashAccountRequired` (margin borrowing is riba — the posture's whole claim: it sidesteps
+nothing on PDT, where the cadence, not the posture, is the safety; the refusal says so and
+names the fix — set the account's max margin multiplier to 1), and a classification that
+cannot be read at all raises the same
+fail-closed refusal, cause chained and folded into the message. The declared half is
+`BrokerCapabilities.cash_only=True`, rendered as "cash only" in `keel brokers list`. The
+operator-facing walk (including the T+1 settlement and opt-out obligations) is the
+runbook's "Account posture" and "T+1 settlement" sections.
+
 ## What works
 
 | Capability    | Detail                                                                       |
@@ -25,6 +42,7 @@ there is no configuration path from a paper credential to
 | Order status  | `get_order` maps Alpaca's status enum to the port's vocabulary; unknown statuses stay `PENDING`. |
 | Cancel        | 204 from `DELETE /v2/orders/{id}` is the venue confirmation; 404/422 and any transport failure answer `False`. |
 | Session       | `is_market_open()` reads the venue's clock (`/v2/clock`) — no local calendar. |
+| Posture       | `verify_cash_account()` at broker build: `/v2/account`'s `multiplier` must be the cash classification (1); margin (2/4) and unreadable answers refuse, fail-closed (#372). |
 | Rate limits   | 429 retried with `Retry-After` when sent, exponential backoff otherwise, bounded attempt budget (FR-11). |
 
 ## Fees (FR-7)
 
@@ -5,6 +5,6 @@
 Market Data APIs -- no Alpaca SDK, no third-party adapter code.
 """
 
-from keel_broker_alpaca.adapter import AlpacaAdapter
+from keel_broker_alpaca.adapter import AlpacaAdapter, CashAccountRequired
 
-__all__ = ["AlpacaAdapter"]
+__all__ = ["AlpacaAdapter", "CashAccountRequired"]