> ## Documentation Index > Fetch the complete documentation index at: https://docs.lerian.studio/llms.txt > Use this file to discover all available pages before exploring further. # Como funciona a originação > O caminho que uma proposta de empréstimo percorre: a que ela se amarra, as quatro decisões do ciclo de vida, a única transação que a desembolsa e a conta de empréstimo que ela deixa. A originação transforma um pedido de crédito em uma conta de empréstimo viva. Ela tem quatro decisões e uma transação que faz tudo de uma vez. Esta página segue uma proposta de enviada até desembolsada sobre o perfil genérico `XX`. Um empréstimo regulado brasileiro é originado pelo pacote regulatório do Brasil, não por `POST /api/v1/loan-applications`. Leia o [Pacote regulatório do Brasil](/pt/lender/brazil-regulatory-pack) para esse caminho. ## A que uma proposta se amarra *** Uma proposta se amarra a uma **versão do produto**, nunca a um produto sozinho. A versão fixa a moeda, os termos de taxa e a base de apropriação, então um contrato sempre rastreia até os termos com que foi criado. Uma versão posterior não muda um empréstimo que já existe. Amarre um **perfil contábil** a essa versão antes de desembolsar. O desembolso monta o posting dele com os lançamentos do perfil, e um desembolso sem perfil falha. Veja [Definir um produto de empréstimo](/pt/lender/define-a-loan-product). ## Pré-visualize, se quiser *** A pré-visualização de cronograma calcula as parcelas e a divulgação de custo para termos prospectivos. Ela não cria nada e não muda nada. Use-a para mostrar ao tomador como o empréstimo fica antes de alguém se comprometer. Esta etapa é opcional. ## Envie *** A chamada de envio cria a proposta em `pending_approval`. Ela carrega a versão do produto, o tomador, o principal solicitado, a taxa de juros **mensal** solicitada, a quantidade de parcelas e uma data esperada de desembolso. O Lender aceita até 600 parcelas. Um campo não vai no body: o **oficial designado**. O Lender o toma do sujeito autenticado da chamada de envio. As decisões seguintes são verificadas contra esse oficial, então envie com a identidade que também vai aprovar e desembolsar. ## Decida *** Exatamente uma decisão resolve uma proposta pendente. | Decisão | Resultado | Quem pode agir | | ------- | -------------------------------------------------------- | ---------------------------------------------------------------------------------- | | Aprovar | `approved`, com o valor aprovado e um horário de decisão | A política de aprovação da jurisdição. Sob o perfil genérico, o oficial designado. | | Recusar | `rejected` | O oficial designado. | | Retirar | `withdrawn` | O tomador, ou o oficial designado. | Uma proposta aprovada ainda pode ser retirada. `rejected` e `withdrawn` são finais, e nada sai deles. O valor aprovado é um limite, não um pagamento. Ele delimita cada desembolso que vem depois. ## Desembolse *** O desembolso move dinheiro, então ele carrega o maior número de guardas. Três coisas vão no request: * Um header `X-Idempotency`. O Lender o exige nesta operação. * O **identificador da conta de empréstimo**. É um UUID que você escolhe, e o Lender não gera um para você. O cronograma, as transações, os encargos e a trilha de auditoria são todos endereçados por ele. * O valor bruto solicitado e o valor líquido entregue. O Lender verifica cinco regras. Ele verifica as quatro primeiras antes de escrever qualquer coisa. Ele verifica a regra de balanço dentro da transação de desembolso, então uma falha ali reverte todo o desembolso. | Guarda | Regra | | ---------- | ------------------------------------------------------------------------------ | | Valor | O bruto não pode exceder o valor aprovado. | | Total | O bruto de todas as tranches precisa ficar dentro do valor aprovado. | | Cronologia | O desembolso não pode ser anterior à decisão de aprovação. | | Identidade | O identificador da conta de empréstimo precisa ser o mesmo em cada tranche. | | Balanço | O líquido precisa igualar o bruto menos as retenções que a jurisdição calcula. | A regra de balanço é a que surpreende os integradores. Sob o perfil genérico não há retenções, então **o líquido iguala o bruto**. Um líquido menor deixa o posting sem fechar e o Lender recusa o desembolso. ## Uma transação, quatro resultados *** Um desembolso é uma única transação de banco de dados. Dentro dela acontecem quatro coisas. O Lender acrescenta um evento de desembolso que registra os valores, a data e o ator que desembolsou. O Lender calcula um cronograma de amortização Price (francês) sobre o principal desembolsado acumulado. Ele guarda o resultado como versão 1 do cronograma, com a razão de mudança `origination`. Sob o perfil genérico o pipeline não calcula nada, então ele não acrescenta nenhuma retenção ao desembolso. O Lender escreve uma intenção de posting balanceada no outbox: principal debitado pelo bruto, caixa creditada pelo líquido, e um crédito para cada retenção. Os quatro são comprometidos juntos, ou os quatro são revertidos juntos. Não existe empréstimo desembolsado pela metade. Se o cronograma não puder ser escrito, ou o posting não balancear, a proposta permanece em `approved`. ## Mais de uma tranche *** Você pode desembolsar uma proposta aprovada mais de uma vez. O status permanece `disbursed`, o Lender acrescenta outro evento de desembolso, e o Lender escreve uma **versão nova do cronograma** sobre o principal acumulado. A versão nova substitui a anterior na leitura. O total das tranches ainda não pode exceder o valor aprovado, e cada tranche usa o mesmo identificador da conta de empréstimo. ## Duas chamadas, uma proposta *** Cada escrita do ciclo de vida declara o status que ela espera encontrar. Quando duas chamadas decidem a mesma proposta ao mesmo tempo, uma ganha e a outra recebe `409 Conflict` sem mudar nada. Um desembolso repetido que não coincide com o primeiro é recusado do mesmo jeito. ## O modelo de estados *** | De | Decisão | Para | | -------------------------------- | ----------- | ----------- | | `pending_approval` | aprovar | `approved` | | `pending_approval` | recusar | `rejected` | | `pending_approval` ou `approved` | retirar | `withdrawn` | | `approved` ou `disbursed` | desembolsar | `disbursed` | ## O que você tem no fim *** * Uma proposta que lê `disbursed`, com um evento de desembolso por tranche. * Uma conta de empréstimo sob o identificador que você forneceu, com o cronograma dela, as transações, os encargos e os eventos de auditoria. * Uma intenção de posting a caminho do ledger. Essa contabilização é assíncrona, então ela cai pouco depois de o request retornar, não durante. * Um evento de ciclo de vida no backbone de streaming para cada transição. Continue em [Fazer servicing de um empréstimo](/pt/lender/service-a-loan). ## Próximos passos *** Registre repagamentos, faça pagamento antecipado, reprograme e corrija uma conta de empréstimo ativa. Os domínios, a costura de jurisdição e o outbox que tira o dinheiro. Regras de posting, rotinas de apropriação e a referência de lançamento que amarra uma contabilização. IOF, CET, consentimento de capitalização e o resto do perfil brasileiro.