Um esboço do que seria a arquitetura do Pix Crédito.
São 4 os personas:
- issuer de crédito
- customer de uma transação
- o shopper de um customer
- seller de uma transação
O customer de uma transação eventualmente pode ser o seller em outra transação.
O shopper é um representante do customer autorizado a fazer transações.
A issuer de crédito é quem vai operar e garantir o Pix Crédito
O uso do Pix Crédito se faz através de 3 formas:
- uso do crédito por parte do customer para obter bens ou serviços de um seller
- pagamento da fatura do customer
- saque do dinheiro a ser recebido pelo seller
Para isso, pressupõe-se que:
- seller é cliente Pix Crédito
- customer é cliente Pix Crédito
- customer já passou por uma análise de risco e tem crédito limitado
- seller receberá automaticamente o dinheiro devido no dia de saque via conta Pix
- customer configurou seu shopper
- todo evento ocorre online
- para todo evento, será mantido um timestamp indicando quando ocorreu
O customer deseja adquirir um bem ou serviço do seller. Shopper (representando o customer) e seller chegam a uma conclusão de quais valores e sobre condição de pagamento desses valores. Seller inicia uma transação, indicando:
- valor
- condição de parcelamento
- shopper
- customer
- identificação do dispositivo usado para criação da transação
Seller recebe de volta o código da transação, valor, condição de parcelamento, shopper e qual o dispositivo usado para iniciar a transação.
O dispositivo é sempre informado a fim de auditoria e garantia de segurança por parte dos operadores.
Nesse momento, shopper recebe a transação, e os atores no sistema podem tomar as seguintes ações:
- shopper: validar a transação
- shopper: negar a transação
- customer: negar a transação
- shopper: se abster de tomar ação
- seller: invalidar a transação
Ao shopper: validar a transação temos ainda 2 cenários:
- o crédito ser aprovado pela issuer
- o crédito ser reprovado pela issuer
Se o crédito for aprovado pela issuer, então a transação atualiza o status para "aprovada", podendo então gerar movimentos.
Porém o crédito pode ser reprovado pela issuer. Nestas circunstâncias, o shopper e o customer serão notificados disto e encorajados a negar a transação, porém a eles será facultada essa escolha, pois há a possibilidade de normalizar o crédito disponível.
O fato de tentar validar a transação (seja ela efetivada com sucesso ou não) implica no envio das seguintes informações:
- identificação do dispositivo usado para validar a transação
- modo de autenticação e validação da autenticação do shopper para aquela transação
Ao shopper: negar a transação, a transação atualiza o status para "rejeitada pelo shopper". Para negar a transação, é necessário que o shopper forneça:
- identificação do dispositivo usado para negar a transação
- modo de autenticação e validação da autenticação do shopper para aquela transação
Ao customer: negar a transação, a transação atualiza o status para "rejeitada pelo customer". Para negar a transação, é necessário que o customer forneça:
- identificação do dispositivo usado para negar a transação
- modo de autenticação e validação da autenticação do customer para aquela transação
O customer tem um curto intervalo de tempo para invalidar uma transação após validada pelo shopper.
Também há a possibilidade de shopper: se abster de tomar ação e deixar a transação sem reação. Após determinado tempo, shopper será notificado sobre a existência da transação em aberto. Após determinado tempo, o customer será notificado sobre a existência de transações em aberto pelo shopper específico.
Finalmente, após determinado tempo, a transação é cancelada, mudando o status para "tempo de autenticação execedido". Isso deve ter mesmos efeitos práticos de negar a transação.
Por fim, há a possibilidade de seller: invalidar a transação. Isso pode ocorrer a qualquer momento antes da validação da transação. Caso ocorra condição de corrida e a requisição de invalidar a transação ocorra após a validação pelo shopper dentro de um determinado intervalor de tempo, a transação passará para o status "invalidada pelo seller".
Para invalidar uma transação, é necessário fornecer:
- identificação do dispositivo usado para negar a transação
- modo de autenticação e validação da autenticação do seller para aquela transação
Invalidar uma transação deve ter mesmos efeitos práticos de negar a transação.
Ao negar a transação, quaisquer pré-cálculos sobre uso do crédito, para esta transação, em cache precisam ser invalidados. O seller é notificado de que a transação específica não foi concluída.
Toda mudança de status de uma transação precisa ser armazenada.
Uma fatura é composta por movimentos e juros. O valor da fatura é o total da soma dos movimentos no intervalo de uso de crédito e a soma dos juros. Além disso, a fatura tem data de publicação, intervalo de datas para receber movimentos, movimentos vindos de parcelamento e data de vencimento.
Movimentos advém de:
- transações
nestes casos, o movimento precisa indicar de qual transação ele advém - taxa de serviço
taxa da assinatura do Pix Crédito, taxa de saque - juros
juros advindos de montante não pago
Será ofertado duas possibilidades:
- pagamento parcial do montante devedor
- pagamento total do montante devedor
Pagamentos são feitos via Pix endereçados a issuer, identificando a fatura ao qual o pagamento se refere. Pagamentos são identificados como advindos de transações externas.
As taxas de serviço entram como movimentações advindas de transações externas, tendo como beneficiário a issuer. Será cobrado um custo de anuidade para que o customer possa usar os serviços do Pix Crédito.
Caso não aconteça pagamento o suficiente para cobrar o montante devedor e os juros no vencimento da fatura, juros passarão a correr.
TODO
Dado um customer que tem limite de crédito C,
sendo que já consumiu D, e shopper do customer
que foi configurado com limite de crédito C' <= C
e que consumiu D' <= D, uma transação T de valor
T.vr pode ser aprovada se:
D + T.vr <= CD' + T.vr <= C'D' < C'
Caso todas as condições sejam aprovadas, a transação é devidamente aprovada, mudando de status para "aprovada".
Caso haja condições de aprovação de crédito não sejam
atendidas, a transação T não é aprovada e as
condições que não foram atendidas para aprovar a
transação são informadas ao customer e ao
shopper.
De posso da informação do porquê que determinada transação não foi aprovada, o customer pode tomar alguma ação:
- pagamento de fatura (diminuindo
D) - pedido de aumento de limite de crédito (aumentado
C) - configurar o shopper para um limite maior
(aumentando
C') - aprovação individual desta transação
No caso de aprovação individual desta transação,
teremos que D' > C', a transação vai para o
status de "aprovada" e será colocado como modo de
autenticação:
- identificação do dispositivo usado do shopper para validar a transação
- modo de autenticação e validação da autenticação do shopper para aquela transação
- identificação do dispositivo usado do customer para validar a transação
- modo de autenticação e validação da autenticação do customer para aquela transação
Outras formas de aprovação de crédito podem ser descritas no futuro, como a possibilidade de limitar valores altos de transações, limitação diária de shopper ou outra limitação.
As datas de fatura dos customers podem não coincidir com as datas de saques dos sellers, isso implica que há o risco de haver saques para os sellers antes de haver o pagamento. Isso pode ser mitigado tendo capital de giro. Eventualmente empréstimos deverão ser adquiridos para que não haja perda de trustness por parte dos sellers.
Também há o risco de o customer não arcar com o seu gasto do mês, pagando menos do que o montande devedor total, ou até mesmo menos do que o "mínimo" calculado. Para esse tipo de situação, enquanto for sustentável, cobrar os juros para no mínimo cobrir o gasto com dinheiro empenhado para pagar os sellers.
Caso a situação com o customer se torne insustentável, pode-se vender a dívida do customer para algum serviço de proteção ao crédito para mitigar o prejuízo.
- taxa de assinatura do serviço: customer
- taxa de saque: seller
- juros sobre montante devido: customer
A principal fonte deve ser focada na taxa de saque. Essa modalidade de arrecadação de dinheiro não se dá diretamente através da cobrança do seller.
Explicar que se ganha retendo valor pago pelo customer.