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 no webhook de rejeição (data.status = 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 /api/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 a elegibilidade rejeita, você recebe um webhook LOAN_UPDATE com data.status = rejected e o motivo em data.reason:

{
  "event": "update",
  "data": {
    "entity_id": "OP-042",
    "status": "rejected",
    "reason": "<código canônico definido na homologação do fundo>"
  }
}

Os reason canônicos são definidos junto da implementação dos critérios — cada fundo recebe sua lista no momento da homologação. Não há endpoint público para listar os critérios: a lista acordada é entregue pela IORQ na homologação.

4. Próximos passos