FAQ — Perguntas frequentes
← Simulador · Participação · Fórum
O que é RAROC e como é calculado?

RAROC (Risk-Adjusted Return On Capital) mede o quanto uma posição/estratégia retorna por unidade de capital regulatório consumido. É a métrica que conecta o trading book ao ROE do banco — e o "RYSk" no nome do app é exatamente esse Adjusted Return Over Capital.

Fórmula:

RAROC = (P&L esperado − funding cost − EL) / Capital required
      ≈ P&L / Capital required    (trading book onde EL ≈ 0)

Onde:

  • P&L esperado: ganho anualizado da estratégia (mid-market, líquido de slippage)
  • Funding cost (FTP): custo de financiar Initial Margin no CCP + prêmio pago em long options + posição comprada à vista (CDI + spread). Para TRS, é a perna de funding (CDI + spread × notional)
  • EL (Expected Loss): ≈ 0 no trading book puro (sem exposição de crédito de carrego). Diferente de zero quando há TRS, swap OTC, ou bonds — vira o CVA + DRC
  • Capital required = 8% × RWA total, onde RWA total = RWA mercado (SbM: delta + vega + curvature × 3 cenários ρ) + RWA contraparte (SA-CCR) + RWA CVA + RWA default (DRC)

Hurdle — o mínimo de P&L pra valer a pena alocar capital:

Hurdle = CoE × Capital_deployed
       = CoE × CapRatio × RWA

Se RAROC ≥ CoE → posição é accretiva (paga ROE acima do exigido pelos acionistas).
Se RAROC < CoE → posição é dilutiva (consome capital sem retornar o suficiente).

Exemplo com CoE 15% e CapRatio 9%:

  • RWA da posição = R$ 7,4M → Capital required = 8% × 7,4M = R$ 595k
  • Hurdle = 15% × 9% × R$ 7,4M = R$ 100k/ano
  • P&L esperado R$ 200k → RAROC = 33,6% → surplus R$ 100k acima do hurdle (accretiva)
  • P&L esperado R$ 50k → RAROC = 8,4% → déficit R$ 50k abaixo do hurdle (dilutiva)

Bancos top-tier perseguem RAROC de 15–25% no trading book. Abaixo de 10% costuma sinalizar que a estratégia não justifica o capital — melhor reciclar pra outra ideia.

Discussão mais profunda (alavancas pra melhorar RAROC, decomposição por audiência, integração com ROE consolidado) → ver pergunta "Como o RWA conversa com o ROE do banco?" abaixo.

O que é "vol implícita" (IV) e por que ela importa pro RWA?

IV (Implied Volatility / Volatilidade Implícita) é a vol anualizada que vai como input pro Black-Scholes para calcular delta, vega, gamma e preço teórico da opção.

Formato decimal: 0.35 = 35% de vol anualizada.

Como obter o valor:

  • Da plataforma de trading (Profitchart, Tradezone, MetaTrader — todas mostram "IV" ou "Vol Impl.")
  • Bloomberg / Refinitiv
  • Reverse-engineer via BSM a partir do preço de mercado da opção

Heurísticas por ativo:

  • PETR4 ATM 6m: ~35-45%
  • Índice (BOVA11) ATM 6m: ~22-30%
  • Small caps: 50%+

Por que importa pro cálculo de RWA:

  • Delta da opção muda com IV (mais vol → delta mais "ATM-like")
  • Vega depende diretamente — vega_sens = qty × mult × ν × σ
  • Curvature usa IV pra reprecificar nos shocks ±RW%

Sem IV exata? O simulador é what-if — rode 30% e 45% pra ver a sensibilidade.

De onde vêm os 13 buckets de equity? Qual norma define a alocação?

Origem: BCBS d457 (Basel III "Minimum capital requirements for market risk", jan/2019), capítulo MAR21, parágrafos 83-86. No Brasil isso é a Resolução BCB nº 470/25 (publicada 30/abr/2025, vigência mandatória 1/jan/2027 para S1-S3), que adota os mesmos parâmetros.

3 eixos de classificação:

EixoCritério
Market cap≥ USD 2 bi = large; menor = small (MAR21.84)
EconomiaLista fechada Basel: US, Canadá, UK, Eurozona, JP, CH, NO, SE, DK, AU, NZ, SG, HK, KR, IL = advanced. Resto (incl. Brasil) = emerging
Setor4 grupos (A: consumer/health/util; B: telecom/industrials; C: materials/energy/mining; D: financials/RE/tech)

Os 13 buckets (texto regulatório):

#CapEconomiaSetorRW Δ
1LargeEmergingConsumer, Transport, Admin, Healthcare, Utilities55%
2LargeEmergingTelecom, Industrials60%
3LargeEmergingMaterials, Energy, Agriculture, Manufacturing, Mining45% ← PETR4/VALE3
4LargeEmergingFinancials, Real Estate, Tech55%
5LargeAdvancedConsumer/Transport/Admin/Healthcare/Util30%
6LargeAdvancedTelecom, Industrials35%
7LargeAdvancedMaterials/Energy/Mining40%
8LargeAdvancedFinancials/RE/Tech50%
9SmallEmergingTodos70%
10SmallAdvancedTodos50%
11Other / unclassified70%
12Equity index — large advanced15%
13Equity index — outros25%

Por que esses números? Calibração empírica do BCBS — janelas históricas de 10 anos com stress nas piores 250 obs (estilo VaR 99%). Quanto mais homogêneo o bucket, menor o RW. Small cap emerging = ruído alto e iliquidez → 70%.

Por que existem buckets? Pra ter uma matriz de correlação tratável. Sem buckets, 50k+ ações globais = matriz 50k×50k impossível de calibrar. Com 13 buckets: 169 pares (78 únicos), tudo pré-calibrado pelo BCBS. Dentro do bucket aplica ρ, entre buckets γ.

Como o app classifica: yfinance.Ticker(ticker).info traz sector + country + marketCap + currency. App converte cap pra USD e aplica regras. Sem dados → bucket 11 (other, 70% — penaliza).

Override manual: use o dropdown "Bucket" no formulário quando adicionar a posição se quiser sobrescrever a classificação automática.

Fontes:

Faz sentido alocar capital em compra de opção? Meu max loss não é só o prêmio?

Pergunta clássica de mesa de derivativos. Sim, regulatoriamente faz sentido, mas tem assimetria que o FRTB SA não captura bem.

Por que o regulador cobra capital em long option: o capital não cobre a perda no vencimento. Cobre o MTM loss em estresse durante o período de holding (10-60 dias dependendo do bucket).

ConcepçãoO que mede
Sua visão"Max loss = prêmio" → correto no vencimento
FRTBMax stress MTM em N dias → diferente
Exemplo: você compra call ATM PETR4 por R$ 1.000 de prêmio. Daqui a 10 dias, IV crash + spot caiu 5% → MTM = R$ 200. Você ainda poderia segurar até o vencimento, mas o balanço marca hoje, não no vencimento. Outras posições do book exigem caixa → você é forçado a vender no MTM ruim. Capital regulatório é o buffer pra absorver esse hit.

Onde a SA-FRTB realmente over-charges: não diferencia downside-bounded de downside-unlimited. Trata long call e short call simetricamente em Delta. Quem captura isso direito é o Internal Models Approach (IMA), que usa Expected Shortfall em cenários reais. Mas IMA exige aprovação BCB e modelo proprietário.

3 vantagens já embutidas no FRTB SA pra long options:

  • Curvature = 0 pra long gamma. Long option tem CVR_up e CVR_down negativos (ganho de convexidade). Aggregator faz max(CVR, 0)² → vira zero. Short option paga curvature cheia.
  • Long deep OTM = capital quase zero. Delta ≈ 0 → Delta SbM ≈ 0. Vega ≈ 0 também. Lottery ticket capital-free.
  • Vega charge ≈ 20-40% do prêmio pago. Razoavelmente alinhado com "max stress loss antes do vencimento".

Tabela: onde FRTB SA é justo vs onde penaliza demais:

SituaçãoFRTB SA cobraFaria sentido cobrar
Long call ATMΔ + Vega (Curv=0)Só Vega + théta
Long call ITMΔ cheiaΔ × prob. ITM
Long put OTM como hedgeQuase nada Quase nada
Long call OTMQuase nada Quase nada
Short optionCheio (Δ+V+C) Cheio (downside ilimitado)

Estratégias práticas pra eficiência de capital:

  1. Buy options em vez de spot pra direção quando quer convexidade — Curvature charge fica em zero.
  2. Evite long ATM com delta > 0.5 se SbM Delta tá pesado — prefira slightly-OTM (mais convexo, menos delta).
  3. Long vol structures (calendars, double-no-touch synthetics) podem zerar Delta e ter Vega bem distribuído.
  4. Hedge com short do underlying (o que o otimizador faz): zera Delta mas mantém Vega ≈ prêmio. Esse é o piso natural de capital pra um book de long options.

Conclusão direta: sim, regulatoriamente cobra. Mas buying options é mais capital-efficient que spot pra exposição direcional, principalmente OTM. Mesas de prop usam opções exatamente pra estender alavancagem sem estourar o limite RWA.

Fiz delta-hedge e o SbM Delta não foi a zero — bug?

Provavelmente não é bug. Após otimização full delta-neutral, o SbM Delta tem que cair pra próximo de zero. A matemática garante:

WS_k = delta_sens_k × RW
Após hedge, delta_sens_k = 0 ∀ k → WS_k = 0 → K_b = 0 → SbM Delta = 0

Se vê só queda parcial, 4 causas comuns:

  1. Você clicou só "Calcular" mas não "Aplicar ajustes". "Calcular" só mostra preview no chart. Só "Aplicar" reescreve as posições. Sem aplicar, o painel de Risco continua mostrando o estado atual.
  2. Editou spot manualmente mas não pelo valor exato sugerido. Hedge parcial → SbM Delta cai proporcional. Pra zerar precisa do número exato em "Spot ótimo (ações)".
  3. Vega/Curvature estão mascarando. Confira os 3 sub-charges separadamente:
    • SbM Delta deve cair pra ~zero
    • SbM Vega fica igual (opções não mudaram)
    • SbM Curvature fica igual
    Total cai pela queda do Delta apenas. Se Vega = 100k e Curvature = 20k, Total não cai abaixo de 120k mesmo com hedge perfeito — esse é o piso inerente das opções.
  4. Edge case real: opções em buckets com γ baixo (ex: bucket 3 + bucket 11 = γ_{3,11} = 0), e o segundo nome não conseguiu virar delta-neutral porque você não trada o spot dele. Aí sobra cobertura. Raro mas possível.

Diagnóstico rápido: compare os 3 sub-charges (Delta / Vega / Curvature) antes e depois. Só Delta deve mudar.

O que significa cada coluna do "RWA Capital"?
MétricaO que é
SbM Delta Capital sobre exposição linear (delta) ao spot. Maior parcela em books direcionais ou desbalanceados.
SbM Vega Capital sobre exposição a vol implícita. Só opções contribuem. Zero pra books só-spot.
SbM Curvature Capital sobre convexidade (gamma). Long gamma = 0 (você ganha em qualquer direção). Short gamma = cheio.
Capital Required (8%) SbM Total = soma dos 3 sub-charges. É o capital mínimo que o banco precisa ter pra cobrir esse book sob FRTB.
RWA (× 12.5) Risk-Weighted Assets = Capital × 12.5 (porque 8% = 1/12.5). É a forma como esse risco aparece no índice de Basileia do banco.

Cenários dominantes (medium/high/low): o FRTB roda a agregação em 3 cenários de correlação (low = ρ × 0.75-ish, medium = ρ padrão, high = ρ × 1.25). O painel mostra qual venceu por sub-charge. "High" é típico de books long-only no mesmo bucket; "low" de books com short hedges em buckets distintos.

Por que o threshold de USD 2 bilhões pra large cap?

Calibração empírica do BCBS na fase de finalização do FRTB (2017-2019). O estudo de impacto (QIS) mostrou que acima de ~USD 2bi, as ações têm:

  • Liquidez profunda (bid-ask < 20 bps)
  • Cobertura analítica robusta (≥ 5 analistas)
  • Padrão de correlação estável com pares do mesmo setor

Abaixo desse threshold a volatilidade é mais idiossincrática e a correlação intra-setor é menor → risk weight maior (70% pra small emerging, 50% pra small advanced).

Conversão de moeda: o threshold é em USD. Pra ações BR (PETR4 ~R$200bi em BRL), divide por ~5 → ~USD 40bi → large. Pra small caps brasileiras tipo SMLS3 (~R$2bi BRL ≈ USD 400mi) → small. A app faz esse FX automaticamente.

Como o RWA "conversa" com o ROE do banco? O que é RAROC?

O capital alocado pra suportar seu book não vive isolado — ele compete pelo capital próprio do banco que o acionista mede pelo ROE (Return on Equity).

A equação que conecta os dois:

            Lucro Líquido        P&L da posição
ROE_pos  =  ──────────────  =  ──────────────────────
              Equity            CapRatio × RWA

Onde CapRatio é o índice de capital efetivo que o banco roda (não os 8% mínimos do Basel, mas tipicamente CET1 ~9-11% por causa de buffers regulatórios e Pillar 2).

Reorganizando, pro ROE de uma posição:

ROE_pos = RoRWA / CapRatio
        = (P&L / RWA) / CapRatio

Hurdle = mínimo de P&L que a posição precisa gerar pra não dilluir o ROE médio do banco:

Hurdle_P&L = CoE × CapRatio × RWA

Exemplo com CoE 15% e CapRatio 9%:

  • RWA da posição = R$ 7,4M → Capital required = R$ 595k
  • Hurdle = 15% × 9% × R$ 7,4M = R$ 100k/ano
  • Se a estratégia espera P&L de R$ 200k/ano → RAROC = 33,6%, surplus de R$ 100k acima do hurdle
  • Se espera R$ 50k/ano → RAROC = 8,4%, déficit de R$ 50k — ROE-dilutivo

RAROC (Risk-Adjusted Return On Capital) é a métrica que sintetiza isso:

RAROC = (P&L esperado − funding cost − EL) / Capital required
      ≈ P&L / Capital required    (no trading book FRTB onde EL≈0)

Bancos top-tier perseguem RAROC de 15-25% na trading book. Abaixo de 10% costuma sinalizar que a estratégia não justifica o capital.

3 alavancas que o trader tem pra "conversar com ROE":

AlavancaComoEfeito ROE
Reduzir RWA com mesmo P&LDelta-hedge, fechar tails, OTM em vez de spot↑ direto
Aumentar P&L com mesmo RWAMelhor entry/exit, capturar skew, evitar théta negativo↑ direto
Reciclar capitalFechar trades com RAROC baixo → liberar RWA pra trades com RAROC alto↑ por composição

Hierarquia de quem olha o quê no banco:

  • Trader: P&L diário, slippage, hit ratio
  • Risk manager: RWA consumed, VaR utilization, limit usage
  • Desk head: RAROC por trader / strategy
  • CFO: ROE consolidado por unidade
  • Diretoria: ROE banco vs ROE pares vs CoE

Quando o ROE cai abaixo do CoE, acionista pressiona conselho → CEO → CFO → cortes de budget de RWA nas mesas. Trader precisa cortar trade ou justificar com RAROC melhor.

O widget RAROC no simulador faz exatamente esse cálculo: digita o P&L anual esperado do book, configura CoE e CapRatio, e a app mostra se está accretive (✓), marginal (⚠) ou dilutive (✗).

Diferença entre SbM Total e RWA?

Relação direta: RWA = SbM Total × 12.5.

SbM Total é o capital required (em R$) pra cobrir o risco de mercado desse book. É o que o regulador pede como cushion.

RWA é a representação desse mesmo risco em "ativos ponderados por risco" — a unidade que vai no denominador do índice de Basileia.

Índice de Basileia = Capital Próprio / RWA Total

Onde RWA Total = RWA Crédito + RWA Mercado + RWA Operacional + ...

O fator 12.5 = 1/0.08 vem da regra Basel de que bancos devem ter capital próprio ≥ 8% × RWA. Então pra ter R$ X de capital coberto, você precisa de R$ 12.5 × X em RWA.

Exemplo prático: se seu book pede R$ 100k de SbM Total, isso consome R$ 1.25M de RWA. Se o banco tem R$ 10bi de RWA total, esse book é 0.0125% do balanço regulatório.

O que é SA-CCR (Standardised Approach for Counterparty Credit Risk)?

SA-CCR é o framework Basel III (BCBS d424, mar/2014) que mede o risco de crédito de contraparte em derivativos. Substitui o antigo Current Exposure Method (CEM).

A fórmula central:

EAD = α × (RC + PFE)
       onde α = 1.4 (regulatory scaling factor)
       RC = Replacement Cost = max(MV − collateral, threshold)
       PFE = Potential Future Exposure = AddOn × Multiplier

Pra equity single-name, o AddOn factor é 32% do notional (MAR21 table).

3 tratamentos de counterparty no app:

  • B3 (CCP-cleared): QCCP charge ~2% × notional × peso 2%. Baixíssimo.
  • OTC Banco: SA-CCR cheio × peso 20%.
  • OTC Corporate: SA-CCR cheio × peso 100%. O mais caro.

Capital SA-CCR = EAD × peso × 8%. Pra uma opção equity de R$ 100k notional:

CPCapital SA-CCR
B3R$ 4.5
OTC BancoR$ 716
OTC CorpR$ 3.580

Por isso clearing em CCP é tão importante: reduz CCR em ~100×.

O que é CVA (Credit Valuation Adjustment)?

CVA é o ajuste de valor por risco de default da contraparte. Em um derivativo OTC com prazo longo, mesmo que o valor "fair" seja R$ X, o valor REAL pra você é menor — porque a contraparte pode default antes do vencimento.

O charge regulatório (Basel III SA-CVA) cobra capital sobre essa incerteza:

CVA = spread_proxy × EAD × √M
       onde M = time to maturity (capped at 5y)

B3-cleared = CVA zero: o CCP é a contraparte de todos, e ele é assumido como infinitamente solvente (na prática tem default fund, margin requirements pesadas, garantias).

OTC = CVA cobrado: o app usa spread proxy de 25 bps (banco) ou 50 bps (corporate) — alinhado com PD anuais típicos de IG corporate Brasileiro.

CVA é "small but real" — em books de equity options 6-12 meses, fica em ~0.5-2% do EAD. Cresce com prazo (raiz quadrada de M).

Como funciona o modelo de FTP (Funding) + HQLA no Resumo?

O FTP (Funds Transfer Pricing) é o que o banco cobra internamente pra você usar o balance sheet. O Resumo usa um modelo 3-bucket calibrado pelo tipo de cash:

Cash usageFTP aplicadoRazão
IM no CCP (margem)spreadB3 paga SELIC sobre collateral, banco recupera RFR
Prêmio pago (long option)RFR + spreadcash sai e some, sem income offsetting
Spot longRFR + spreadcash tied up no ativo, sem RFR income
Spot shortaluguel ratecash do short sale rende RFR, mas paga aluguel

HQLA buffer (Liquidity Coverage Ratio): bancos precisam manter assets líquidos (HQLA) pra cobrir 30 dias de outflow stress. Equity em Ibovespa conta como HQLA Level 2B com haircut 50% (Basel III LCR30).

O app aplica:

HQLA_gross  = 0.5% × Capital_total                     # cost of buffer
HQLA_credit = (1 - 50%) × Σ (long spot Ibovespa MV) × 0.5%
HQLA_net    = max(0, HQLA_gross − HQLA_credit)

Resultado: long spot em PETR4/VALE3/etc. compensa parcialmente o charge HQLA do book. Long spot em ticker pequeno (não-índice) — sem credit.

Toda a calibração (FTP spread, RFR, aluguel, HQLA haircut, lista Ibovespa) é configurável no topo da página Resumo.

FTP é taxa ANUAL × tempo da posição. Não é flat fee. Cada posição contribui pra annualized FTP cost proporcional à fração do ano em que ela está viva:

FTP_cost_anual_pos = rate × notional × min(M, 1)

# Spot (perpetual)    → MF = 1 (sempre full ano)
# Opção / TRS / etc   → MF = min(years_to_maturity, 1)

Implicação: short call 3m contribui só 0,25 × annual rate × IM pra FTP_margem (não rate × IM). TRS 6m paga só 0,5 × annual funding rate × notional.

Aplicado em FTP_margem (via IM × MF), FTP_premium (premium × MF), e TRS funding leg (notional × MF). FTP_spot e aluguel ficam sem MF (spot é perpétuo).

Quais posições pagam IM (margem)? Long spot, long option, OTC...

O IM (initial margin) só é cobrado onde há obrigação contingente futura E o trade é cleared por um CCP padronizado. Decompondo:

PosiçãoIM?Razão
Long spotNÃOAção é storable. Pagou full price, banco já é dono. Sem ongoing obligation.
Short spot (B3)NÃOA aluguel tomado (garantia BTC ao prestador) já cobre o lado de margem. Sem IM separado no CCP.
Long option (call/put)NÃOPremium pago = MAX loss. CCP não cobra IM do comprador.
Short option (B3)SimPotencial payout sem aluguel cobrindo. CCP cobra IM autônomo via CORE.
TRS B3 clearedSimDaily MTM via CCP.
Qualquer OTC (TRS bilateral, opção OTC, etc)Sim, mas bilateralIM negociado per-ISDA/CSA, varia por contraparte. NÃO dá pra auto-computar — usuário precisa setar manual_im.

Proxy IM no app — per-posição (sem netting de IM requirement):

O CCP cobra IM por linha de posição. Long inventário pode reduzir o cash IM via collateral pledge (recurso de liquidez), mas o IM REQUIREMENT do short não desaparece — ele só pode ser satisfeito via stock collateral em vez de cash.

im_pos = manual_im                               # SEMPRE prevalece
im_pos = 0                                       # long pos (qty ≥ 0): sem obrigação
im_pos = 0                                       # short SPOT B3: aluguel garantia cobre
im_pos = 0                                       # OTC sem manual_im: bilateral
im_pos = |delta_sensitivity| × risk_weight       # short option B3 ou TRS B3-cleared

Stock collateral (recurso de liquidez): long spot unencumbered pode ser pledged pra satisfazer o IM requirement. Resultado: cash_IM = max(IM_required − long_collateral × (1 − haircut), 0). FTP margem cobra spread só sobre o cash_IM residual. Veja seção separada do FAQ sobre o breakeven pledge vs lend.

Para OTC: usuário deve setar manual_im no form. Sem isso, IM=0 e a economics vai subestimar o trade.

Visível no app: cada posição mostra IM R$ X na linha 2 da lista. Long spot, long option e OTC sem manual_im mostram IM 0 explicitamente.

Como é calculado o delta de uma opção? E por que long put + short call ≡ TRS payer?

Black-Scholes-Merton delta (em greeks.py):

Δ(C) = e^(-q·T) × N(d1)              # call
Δ(P) = e^(-q·T) × (N(d1) − 1)        # put (negativo)

Onde:

  • q = dividend yield (default 0% no app — ver justificativa abaixo)
  • T = anos até vencimento (Act/365.25)
  • N(·) = CDF normal padrão
  • d1 = [ln(S/K) + (r − q + σ²/2)·T] / (σ·√T)

Delta agregada da posição em ações-equivalentes:

delta_sensitivity = qty × delta × spot     (em BRL por shock relativo)

Pra ATM (S = K, r = 10%, σ = 30%, T = 0.25, q = 0): Δ(C) ≈ +0,53, Δ(P) ≈ −0,47.

Put-call parity em delta

Da BSM segue:

Δ(C) − Δ(P) = e^(-q·T)

Com q = 0: Δ(C) − Δ(P) = 1 exato. Long put + short call mesma K, T tem delta exatamente −1 per share (= synthetic short forward).

Equivalência com TRS

Como o TRS payer no app modela delta −1 per share notional (sem desconto de div, assumindo dividend pass-through padrão B3), a parity dá equivalência exata:

long put 1000 K @ T  +  short call 1000 K @ T  ≡  TRS payer 1000 notional, funding leg @ r

→ ambos: delta_sensitivity = -1000 × spot
→ ambos: zero vega, zero curvature (synthetic forward é linear)
→ ambos: zero JTD (DRC) pelos longs e shorts netarem no issuer-level

Por que DEFAULT_DIV_YIELD = 0 no app

Decisão deliberada por 3 razões:

  1. Consistência com TRS: TRS no app tem delta-1 exato (dividend pass-through). Pra parity holds, opções precisam usar q = 0 também.
  2. Realismo BR: dividends em ações brasileiras são lumpy/discretos, não contínuos. O ajuste e^(-q·T) é uma aproximação contínua que distorce mais que ajuda pra prazos curtos típicos da mesa.
  3. Override por posição: trader pode setar div_yield específico (ex: VALE no ex-div) numa OptionPosition se quiser modelar o caso concreto.

Sanity check da parity no app: adicione no front-end long put 1000 PETR4 K=35 + short call 1000 PETR4 K=35 mesma expiry e veja em Por bucket que delta agregado ≈ −1000 shares × spot. Compare com TRS payer 1000 PETR4 mesma maturity: SbM delta dá zero quando ambos estão no book (netting perfeito).

Como o trading cost é anualizado? (spot vs derivativo)

Convenção do app: a base de bps (bid-ask + corretagem + IOF) é cobrada sobre o turnover de cada posição, multiplicada pelo churn natural:

  • Spot (ação): churn = 1. Sem vencimento, paga bid-ask uma vez na entrada e fica. Custo anual = bps × MV.
  • Opção / TRS: churn = 360 / dias_corridos_até_vencimento. Cada rolagem paga bid-ask de novo pra manter a exposição.

Exemplos:

PosiçãoTurnoverChurnCost (defaults: 4,5 bps)
PETR4 spot 1000 @ R$ 35R$ 35.0001,0×R$ 15,75
Call PETR4 90d @ premium R$ 1,50 × 1000R$ 1.500360/90 = 4,0×R$ 2,70
Call PETR4 30d @ premium R$ 0,80 × 1000R$ 800360/30 = 12,0×R$ 4,32
TRS 1y notional R$ 50kR$ 50.000360/360 = 1,0×R$ 22,50

Observação: a base de turnover de opção é o PREMIUM (MV pago), não a delta-exposure em ações-equivalentes. Em B3, bid-ask de opções é cotado em % do prêmio.

OTC = sem trading cost. Trades bilaterais (TRS, opção OTC, etc) não pagam bid-ask de exchange nem corretagem. O custo embutido no spread negociado vai pra outras linhas (FTP, CVA). Apenas posições com counterparty == "B3" entram no trading cost annual.

Alugar (doado) ou usar como margem? Onde fica o breakeven?

Long spot unencumbered pode ser usado de dois jeitos mutuamente exclusivos — uma ação não pode estar com o tomador E posted como collateral ao mesmo tempo. Cada BRL de inventory gera um alpha diferente em cada uso:

UsoAlpha por BRL/ano
Alugar (doado)loan_out_bps / 10000
Pledge como margem (recurso de liquidez)(1 − margin_haircut) × ftp_spread_bps / 10000

Breakeven sai igualando os dois:

loan_out_bps = (1 − margin_haircut) × ftp_spread_bps

Com defaults do app (margin_haircut = 30%, ftp_spread = 100 bps):

breakeven = 0.70 × 100 = 70 bps
  • Ação com lend_rate < 70 bps (ex: PETR4 ~4 bps doador) → pledge é mais valioso
  • Ação com lend_rate > 70 bps (ex: SMLS3 ~200+ bps doador) → alugar é mais valioso

Constraint operacional: só precisa fazer pledge até cobrir o IM exigido. Excesso de inventory vai pra aluguel sem custo de oportunidade. O orçamento de pledge é:

pledge_budget_gross = IM_required / (1 − margin_haircut)

Algoritmo do app:

  1. Ordena posições long unencumbered por lend_rate crescente (lower first)
  2. Pledge cada posição em ordem até uma de duas paradas: orçamento coberto OU próxima posição com lend_rate > breakeven
  3. Resto vai pra aluguel doado (no rate da posição)

Exemplo: book com 10.000 PETR4 (lend 4 bps) + 10.000 SMLS3 (lend 200 bps), IM proxy = 10k, defaults do app:

  • Pledge budget = 10k / 0.7 ≈ 14.3k MV
  • PETR4 (4 bps < 70) → pledge primeiro: 14.3k pledged ✓ orçamento coberto
  • Resto (35.7k PETR4 + 10k SMLS3) → lent
  • Resultado: cash IM = 0 → FTP_margem = 0; aluguel doado = 35.7k×4bps + 10k×200bps ≈ R$ 214/ano
  • Se pledgeasse SMLS3 (errado): aluguel doado cairia em 14.3k×200bps = R$ 286/ano. O algoritmo evita.

Impacto em HQLA: stock pledged fica encumbered (Basel III LCR §50) → fora do crédito L2B. Stock lent também encumbered. Só o que sobra como free inventory conta como HQLA.

Para desabilitar pledge (ex: book onde regulação local impede ações como margem) → setar margin_haircut_pct = 100% no config bar.