Critérios de elegibilidade

1. Como tratamos elegibilidade

Elegibilidade é a primeira linha de defesa da qualidade da carteira. Os critérios protegem cotistas e cumprem cláusulas do regulamento. Sem enforcement automático, operações inadequadas chegariam ao fundo e seriam rejeitadas só mais tarde — em assembleia ou em auditoria.

📘

Princípio

A IORQ não tem um catálogo fixo de critérios. Qualquer regra de elegibilidade que o regulamento de um fundo exigir — concentração, prazo, taxa, score, relacionamento, perfil do devedor, características do lastro — pode ser implementada. A engenharia da plataforma trata novos critérios como uma extensão natural do motor, não como exceção.

2. O que precisa rolar no setup de cada fundo

Para um fundo entrar em produção, esta etapa precisa estar concluída. É um trabalho conjunto entre gestora (IORQ), originador e — quando aplicável — administradora e bancarizador.

• Levantar o regulamento — quais cláusulas do regulamento do FIDC impõem critérios de elegibilidade? O que está vinculante?
• Alinhar com o originador — quais regras de aceite o originador já aplica no momento da originação? Onde há sobreposição, redundância ou conflito com o regulamento?
• Definir os critérios e seus parâmetros — converter as cláusulas em regras computáveis, com thresholds claros (percentuais, prazos, valores mínimos)
• Implementar no motor da IORQ — cada critério vira uma regra parametrizável aplicada na cessão
• Homologar em sandbox — validar com payloads reais antes de virar a chave em produção
• Documentar para o time do originador — quais reason esperar em loan_rejected e como reagir

🚧

Sem essa etapa, não há cessão em produção

Um fundo pode entrar em sandbox para integração técnica antes da elegibilidade estar 100% definida, mas a liberação para produção depende do conjunto de critérios estar acordado e implementado.

3. Como aparece na API depois de definido

Quando os critérios estão configurados para o fundo, eles rodam automaticamente:

• Na cessão (POST /loan): todos os critérios aplicáveis são avaliados antes do estado mudar para approved. Veja em Ciclo de vida a transição received → approved/rejected.
• Em renegociação: a nova operação passa pelos mesmos critérios — pode ser rejeitada mesmo a recompra da original sendo aceita.
• Não roda em liquidação nem recompra — esses fluxos têm validações próprias.

Quando elegibilidade rejeita, você recebe o webhook loan_rejected com o motivo:

{
  "event": "loan_rejected",
  "originator_proposal_code": "OP-042",
  "fund_id": "...",
  "timestamp": "2026-05-22T11:02:34Z",
  "data": {
    "reason": "<código canônico definido na fase 2>",
    "reason_detail": "Explicação humana com os valores que causaram a rejeição",
    "criteria_applied": ["..."],
    "criteria_failed": ["..."]
  }
}

Os reason canônicos são definidos junto da implementação dos critérios — cada fundo recebe sua lista no momento da homologação. Consulte os critérios configurados para o seu fundo em GET /funds/{fund_id}/eligibility.

4. Próximos passos