O ciclo de vida da proposta
Uma proposta passa por estados nomeados. Cada transição é uma operação distinta, e cada uma guarda um registro de decisão ou de desembolso:
Passos
1
Veja a prévia do cronograma (opcional)
POST /api/v1/loan-applications/preview-schedule calcula o cronograma de amortização para termos em estudo sem originar nada. Quando registra a cotação como oferta, ele retorna o scheduleOfferSnapshotId da oferta, que a proposta pode citar. Use para mostrar parcelas e divulgações antes de alguém se comprometer.2
Envie a proposta
POST /api/v1/loan-applications cria a proposta contra a versão atual do produto. Ela declara o tipo de tomador, e a taxa solicitada deve estar dentro da faixa de taxa da versão.3
Decida
Resolva a proposta com exatamente uma destas opções:
POST /api/v1/loan-applications/{id}/approve: aceite a proposta, com um registro de decisão.POST /api/v1/loan-applications/{id}/reject: recuse a proposta, com um registro de decisão.POST /api/v1/loan-applications/{id}/withdraw: retire a proposta enquanto ela aguarda aprovação ou, depois da aprovação, antes do desembolso.
4
Desembolse
POST /api/v1/loan-applications/{id}/disburse registra os fundos entregues. Ele recebe a chave X-Idempotency que toda escrita desta página recebe. Uma repetição com a mesma chave, portanto, repete a primeira resposta e não registra um segundo desembolso.Uma transação de banco de dados faz commit do evento de desembolso, do cronograma de originação e de uma intenção de lançamento balanceada. Quando a chamada retorna, o empréstimo é uma conta de empréstimo ativa que você passa a gerir daqui em diante.A contabilização no ledger não está nessa transação. Com o relay do ledger configurado, um dispatcher do outbox repassa a intenção ao Midaz logo depois da resposta, pelo perfil contábil do produto. Caso contrário, a intenção fica no outbox. Veja o caminho de lançamento.Toda escrita recebe uma chave de idempotência
Criar uma proposta e movê-la (aprovar, recusar, desistir, desembolsar) exigem todas o cabeçalho
X-Idempotency. O Lender lê a chave nessa grafia e em nenhuma outra. Ele recusa Idempotency-Key e X-Idempotency-Key pelo nome, para que um cliente nunca fique desprotegido em silêncio por ter adivinhado o cabeçalho. Enviar uma dessas junto com o cabeçalho do contrato não é problema. A recusa só dispara quando X-Idempotency está ausente.
A guarda falha fechada. Quando o armazenamento de idempotência não consegue responder, o Lender recusa o pedido com
503 em vez de deixá-lo passar adiante desprotegido.
Criar custa uma chave de propósito: sem ela, um cliente que estoura o tempo na criação e chama de novo cria uma segunda proposta para o mesmo tomador. É a duplicata mais barata de produzir no serviço e a mais cara de desfazer. Ela é cara porque as duas cópias parecem legítimas e só uma pessoa sabe dizer qual é a verdadeira.
Nas quatro escritas de ciclo de vida, você pode conciliar um pedido que termina sem resolução e reenviá-lo sob uma chave nova. Leia a proposta por id e pergunte se ela já está no estado que você queria. O desembolso é a exceção, onde uma chave nova não é uma recuperação segura de jeito nenhum. Uma segunda liberação legítima declara a tranche dela.
O produto precisa estar ativo
A originação lê o status de ativação do produto de empréstimo e recusa um produto que não está ativo, com
LENDER-0225 e um 422. A recusa fica nos três passos que decidem crédito novo: criar a proposta, aprovar e liberar o dinheiro pela API. Um produto desligado depois de a proposta ter sido registrada, portanto, segura essa proposta antes de o dinheiro sair.
Criar uma proposta também precisa nomear a versão corrente do produto, ou o Lender a recusa com LENDER-0226 e um 422. Essa checagem roda na criação e em lugar nenhum mais, porque uma proposta fica a vida inteira na versão em que nasceu. Promover uma versão nova nunca mata, portanto, as propostas paradas na anterior, e cada uma delas contabiliza na versão que nomeou. Veja Defina um produto de empréstimo.
Dois caminhos ficam fora deste portão de propósito:
- A esteira do consignado, que registra um contrato que os sistemas do próprio cliente já averbaram na folha. Recusar um fato que já aconteceu deixaria o livro negando um contrato que o tomador tem na mão.
- Uma renegociação substancial, cujo contrato de substituição herda a versão de produto do contrato que ele substitui. O contrato de substituição herda essa versão esteja esse produto ativo ou não e seja essa versão a corrente ou não. Renegociar é servicing de crédito já escrito. Só uma proposta nova é crédito novo.
O que você recebe
O desembolso produz uma conta de empréstimo, a visão de gestão do contrato vivo, carregando o cronograma, as transações, os encargos e o histórico de auditoria dela. Continue em Faça a gestão de um empréstimo.
O que acontece downstream
O ciclo de vida emite
loan_application.submitted, loan_application.approved, loan_application.rejected, loan_application.withdrawn e loan_application.disbursed, cada um na versão de schema 2.0.0. O desembolso registra uma intenção de lançamento durável e a repassa ao ledger apenas quando você configura o relay do ledger. Leia o caminho de lançamento.
A originação brasileira adiciona passos regulados (divulgação do CET e consentimento de capitalização) cobertos no Pacote regulatório Brasil. O fluxo de consignado com desconto em folha forma um contexto delimitado brasileiro próprio. Veja Consignado privado.
Próximos passos
Faça a gestão de um empréstimo
Registre pagamentos, antecipe, reprograme e corrija uma conta de empréstimo ativa.