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:
| Eixo | Critério |
|---|---|
| Market cap | ≥ USD 2 bi = large; menor = small (MAR21.84) |
| Economia | Lista fechada Basel: US, Canadá, UK, Eurozona, JP, CH, NO, SE, DK, AU, NZ, SG, HK, KR, IL = advanced. Resto (incl. Brasil) = emerging |
| Setor | 4 grupos (A: consumer/health/util; B: telecom/industrials; C: materials/energy/mining; D: financials/RE/tech) |
Os 13 buckets (texto regulatório):
| # | Cap | Economia | Setor | RW Δ |
|---|---|---|---|---|
| 1 | Large | Emerging | Consumer, Transport, Admin, Healthcare, Utilities | 55% |
| 2 | Large | Emerging | Telecom, Industrials | 60% |
| 3 | Large | Emerging | Materials, Energy, Agriculture, Manufacturing, Mining | 45% ← PETR4/VALE3 |
| 4 | Large | Emerging | Financials, Real Estate, Tech | 55% |
| 5 | Large | Advanced | Consumer/Transport/Admin/Healthcare/Util | 30% |
| 6 | Large | Advanced | Telecom, Industrials | 35% |
| 7 | Large | Advanced | Materials/Energy/Mining | 40% |
| 8 | Large | Advanced | Financials/RE/Tech | 50% |
| 9 | Small | Emerging | Todos | 70% |
| 10 | Small | Advanced | Todos | 50% |
| 11 | — | — | Other / unclassified | 70% |
| 12 | — | — | Equity index — large advanced | 15% |
| 13 | — | — | Equity index — outros | 25% |
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:
- Texto Basel: bis.org/basel_framework/chapter/MAR/21
- PDF BCBS d457: bis.org/bcbs/publ/d457.pdf
- Implementação saudita (mesma estrutura, mesmas numbers): SAMA Rulebook 7.72-7.80
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ção | O que mede |
|---|---|
| Sua visão | "Max loss = prêmio" → correto no vencimento |
| FRTB | Max 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ção | FRTB SA cobra | Faria sentido cobrar |
|---|---|---|
| Long call ATM | Δ + Vega (Curv=0) | Só Vega + théta |
| Long call ITM | Δ cheia | Δ × prob. ITM |
| Long put OTM como hedge | Quase nada ✓ | Quase nada |
| Long call OTM | Quase nada ✓ | Quase nada |
| Short option | Cheio (Δ+V+C) ✓ | Cheio (downside ilimitado) |
Estratégias práticas pra eficiência de capital:
- Buy options em vez de spot pra direção quando quer convexidade — Curvature charge fica em zero.
- Evite long ATM com delta > 0.5 se SbM Delta tá pesado — prefira slightly-OTM (mais convexo, menos delta).
- Long vol structures (calendars, double-no-touch synthetics) podem zerar Delta e ter Vega bem distribuído.
- 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:
- 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.
- 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)".
- 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
- 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étrica | O 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":
| Alavanca | Como | Efeito ROE |
|---|---|---|
| Reduzir RWA com mesmo P&L | Delta-hedge, fechar tails, OTM em vez de spot | ↑ direto |
| Aumentar P&L com mesmo RWA | Melhor entry/exit, capturar skew, evitar théta negativo | ↑ direto |
| Reciclar capital | Fechar 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:
| CP | Capital SA-CCR |
|---|---|
| B3 | R$ 4.5 |
| OTC Banco | R$ 716 |
| OTC Corp | R$ 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 usage | FTP aplicado | Razão |
|---|---|---|
| IM no CCP (margem) | só spread | B3 paga SELIC sobre collateral, banco recupera RFR |
| Prêmio pago (long option) | RFR + spread | cash sai e some, sem income offsetting |
| Spot long | RFR + spread | cash tied up no ativo, sem RFR income |
| Spot short | aluguel rate | cash 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ção | IM? | Razão |
|---|---|---|
| Long spot | NÃO | Ação é storable. Pagou full price, banco já é dono. Sem ongoing obligation. |
| Short spot (B3) | NÃO | A aluguel tomado (garantia BTC ao prestador) já cobre o lado de margem. Sem IM separado no CCP. |
| Long option (call/put) | NÃO | Premium pago = MAX loss. CCP não cobra IM do comprador. |
| Short option (B3) | Sim | Potencial payout sem aluguel cobrindo. CCP cobra IM autônomo via CORE. |
| TRS B3 cleared | Sim | Daily MTM via CCP. |
| Qualquer OTC (TRS bilateral, opção OTC, etc) | Sim, mas bilateral | IM 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ãod1 = [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:
- 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.
- 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. - Override por posição: trader pode setar
div_yieldespecí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ção | Turnover | Churn | Cost (defaults: 4,5 bps) |
|---|---|---|---|
| PETR4 spot 1000 @ R$ 35 | R$ 35.000 | 1,0× | R$ 15,75 |
| Call PETR4 90d @ premium R$ 1,50 × 1000 | R$ 1.500 | 360/90 = 4,0× | R$ 2,70 |
| Call PETR4 30d @ premium R$ 0,80 × 1000 | R$ 800 | 360/30 = 12,0× | R$ 4,32 |
| TRS 1y notional R$ 50k | R$ 50.000 | 360/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:
| Uso | Alpha 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:
- Ordena posições long unencumbered por lend_rate crescente (lower first)
- Pledge cada posição em ordem até uma de duas paradas: orçamento coberto OU próxima posição com lend_rate > breakeven
- 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.