1 - Introdução
Bem-vindo ao guia de Transferências Inteligentes, exploraremos essas funcionalidades no cenário do Open Finance Brasil. Este guia destina-se a oferecer uma compreensão aprofundada da ferramenta, delineando como é a implementação no contexto do Open Finance Brasil e como pode transformar a maneira como usuários lidam com suas finanças.
Transferências Inteligentes:
No universo do Open Finance Brasil, a funcionalidade de Transferências Inteligentes destaca-se como uma abordagem estratégica para a gestão inteligente de saldos em contas relacionadas. Seja para consumidores pessoa naturais ou jurídicas, essa API é de implementação obrigatório para os detentores de conta, oferecendo ao ecossistema uma solução que permita a transferência automática de fundos.
O produto está presente na API de pagamentos automáticos, a partir de sua versão 1.0.0. O link para a API pode ser encontrado abaixo.
2 - Regras de negócios para Transferências Inteligentes
| Transferências Inteligentes |
|---|---|
Casos de uso | Transferências Inteligentes e similares (investimentos inteligentes, proteção contra uso desnecessário de cheque especial) |
Configurações de recorrência | |
Motor de recorrência | Criação de um consentimento para recorrência com limites de quantidade, valores e prazos |
Valor | Fixo ou variável |
Modelo de recorrência, intervalos de pagamentos | Restrito aos limites definidos no consentimento |
Gestão da Agenda | Iniciador |
Comanda o pagamento | Iniciador |
Recebedor | PN ou PJ de mesma titularidade |
Primeiro pagamento | Imediato |
Demais pagamentos | Imediato |
Permite pagamentos imediatos | Sim |
Definição do final do período da recorrência | Opcional |
Prazo máximo de duração para recorrência do consentimento | Opcional |
Permite a configurar data de início do consentimento? | Sim |
Permite a configurar data de expiração do consentimento? | Sim |
Permite limites globais do consentimento?¹ | Não |
Permite limites periódicos por consentimento? | Sim |
Permite limites por transação? | Sim |
Processo de adesão | |
Fluxo de adesão | Consentimento FAPI long-lived tokens |
Role no diretório | CONTA, PAGTO |
Será possível editar configurações de recorrência no processo de adesão no Detentor? | Não |
Cancelamento do fluxo da adesão | Via Iniciador ou Detentor |
Permite múltiplas alçadas? | Sim |
Iniciador terá acesso aos status do processo de adesão via Webhook? | Sim |
Adesão tem id de contrato? | Não |
Gestão de adesão | |
Permite edição técnica dos dados do consentimento pós adesão²? | Não |
Cancelamento da recorrência | Pelo pagador, no ambiente da iniciadora ou detentora |
Revogação da recorrência | Iniciador ou Detentor poderão revogar a adesão por motivos de fraude |
Consumação³ da recorrência? | Detentor |
Processo de liquidação | |
Canal para liquidação | Primário |
Dispara o pagamento⁴ | Iniciador |
Onde o cliente cancela o pagamento? | Não é possível |
Erros de saldo insuficiente modificam o status do consentimento? | Não |
Listagem das informações do pagamento | Busca por id do consentimento |
Iniciador é responsável pelo envio da ocorrência do pagamento? | Sim, imediatamente |
Quem avisa o pagador sobre pagamento com falha? | Iniciador |
Responsável pela geração do endToEndId | Iniciador |
A data agendada no consentimento e a data agendada do E2EID podem ser distintas? | Sim |
Qual é o localInstrument utilizado na liquidação? | DICT, INIC e MANU |
Outras informações | |
É possível habilitar crédito? | Sim - Conteúdo explicativo no header da API de pagamentos |
Retentativas
| Não |
Funcionalidade de contestação | MED |
Legenda
1 - Limite específico para um determinado consentimento, por exemplo, limite de R$100 por dia (periódico) ou R$300 para o intervalo do consentimento (global)
2 - O GT questionou o BC sobre o comportamento esperado quando houver a edição –se o usuário deverá ser redirecionado para a detentora ou não para confirmar os novos dados do consentimento
3 - Entende-se como consumação a mudança do estado, por exemplo, após 10/10 parcelas o estado será alterado de aprovado para consumido
4 - Responsável por garantir que no momento do agendamento a liquidação ocorra
3 - Descrição da usabilidade para Transferências Inteligentes
3.1- Jornada de autorização
Diferente dos pagamentos realizados via agendamento recorrente ou pagamentos imediatos, as Transferências Inteligentes possuem consentimentos de longa duração. Entraremos mais no detalhe do processo de consentimento a seguir.
3.1.1 - Jornada 1 - Autorização de consentimento
ID | CAMADA | TIPO | DESCRIÇÃO |
|---|---|---|---|
1 | Pagador | Ação | No app do iniciador, seleciona as transferências inteligentes |
2 | Pagador | Ação | Informa a conta de débito que utilizará para as movimentações |
3 | Pagador | Comunicação | APP do iniciador envia os dados inseridos para o backend do iniciador |
4 | Iniciador | Comunicação | Recebe as informações inseridas no seu backend |
5 | Iniciador | Ação | Processa as informações recebidas |
6 | Iniciador | Ação | Prepara a solicitação para criação de consentimento no PSP Pagador selecionada pelo pagador |
7 | Iniciador | Comunicação | Envia a solicitação de consentimento para o PSP Pagador |
8 | PSP Pagador | Comunicação | Recebe a solicitação de um novo consentimento |
9 | PSP Pagador | Ação | Processa a solicitação de novo consentimento |
10 | PSP Pagador | Comunicação | Informa ao iniciador o sucesso na criação do consentimento |
11 | Iniciador | Comunicação | Recebe a resposta de sucesso na criação do consentimento |
12 | Iniciador | Ação | Prepara o redirecionamento do Pagador para o autenticação e autorização no ambiente do PSP Pagador |
13 | Iniciador | Comunicação | Redireciona o Pagador para autenticação e autorização |
14 | Pagador | Ação | Realiza a autenticação na instituição detentora |
15 | Pagador | Ação | Autoriza o consentimento. Nesta etapa, o Pagador pode selecionar uma conta de débito diferente da informada pelo ITP, basta que ele seja o titular da conta de débito no PSP Pagador. |
16 | PSP Pagador | Ação | Muda o estado do consentimento para AUTHORISED, conforme manifestado pelo Pagador. |
17 | PSP Pagador | Ação | Recolhe as confirmações ou rejeições de todos os aprovadores registrados para a conta |
18 | PSP Pagador | Comunicação | Redireciona o Pagador de volta ao ambiente do Iniciador |
19 | Iniciador | Comunicação | Recebe o Pagador de volta no seu aplicativo. |
20 | Iniciador | Ação | Valida os dados recebidos no redirecionamento |
21 | Iniciador | Ação | Loop para consulta do estado do consentimento até que o mesmo esteja em AUTHORISED |
22 | Iniciador | Comunicação | Notifica ao Pagador que o consentimento foi criado com sucesso e pode ser utilizado. |
23 | Pagador | Comunicação | Recebe notificação sobre o consentimento criado com sucesso e pode ser utilizado. |
3.1.3 - Sobre rejeição e revogação de consentimentos de longa duração.
Tratando agora dos motivos de revogação, a regra é que para um consentimento de longa duração ser revogado, primeiro ele precisou ser aprovado. Apenas consentimentos no status “AUTHORISED” são passíveis de revogação, vamos trazer os motivos de revogação e como eles se aplicam.
REVOGADO_RECEBEDOR: Não se aplica ao produto Transferências inteligentes. Nesse produto, o recebedor e o pagador são de mesma titularidade, portanto, sempre que revogado, será revogado pelo usuário.
REVOGADO_USUARIO: Indica que o usuário pagador, via ambiente do iniciador ou detentor, solicitou a revogação do consentimento de longa duração.
NAO_INFORMADO: Deve ser utilizado para motivos de revogação que envolvam informações que não devem ser compartilhadas no ecossistema por respeito a privacidade do usuário. Ex: Suspeita de Fraude, Bloqueio Judicial.
3.2 - Processo de pagamento
3.2.1 - Fluxo para criação de um pagamento para Transferências Inteligentes
ID | CAMADA | TIPO | DESCRIÇÃO |
|---|---|---|---|
1 | Iniciador | Ação | Dispara processo de transferência |
2 | Iniciador | Ação | Busca informações de contas de usuário habilitadas por ele para realização da transferência |
3 | Iniciador | Ação | Analisa as regras definidas pelo usuário pagador no momento da criação do consentimento de longa duração |
4 | Iniciador | Comunicação | Envia solicitação de access_token |
5 | PSP Pagador | Comunicação | Recebe solicitação de access_token |
6 | PSP Pagador | Ação | Processa solicitação de access_token |
7 | PSP Pagador | Comunicação | Retorna access_token |
8 | Iniciador | Comunicação | Recebe access_token |
9 | Iniciador | Ação | Processa retorno da solicitação de access_token |
10 | Iniciador | Ação | Cria solicitação de transferência |
11 | Iniciador | Comunicação | Envia a solicitação de transferência |
12 | PSP Pagador | Comunicação | Recebe solicitação de transferência |
13 | PSP Pagador | Ação | Processa solicitação de transferência |
14 | PSP Pagador | Ação | Realiza a transferência de fundo |
15 | PSP Pagador | Comunicação | Retorna sucesso na solicitação de transferência |
16 | Iniciador | Comunicação | Recebe sucesso na transferência |
17 | Iniciador | Ação | Processa o retorno da transferência |
18 | Iniciador | Ação | Consulta informações da transferência |
19 | Iniciador | Comunicação | Notifica usuário contratante do sucesso na transferência |
20 | Usuário contratante | Comunicação | Recebe notificação de sucesso na transferência |