APIs de open banking
Open banking: dados de conta e pagamentos por APIs bancárias
Informações de conta e iniciação de pagamento por APIs bancárias reguladas e agregadores, com tratamento de consentimento e de tokens.
Blueprint
Role para o lado para ver o desenho completo.
Open banking: dados e pagamentos com o consentimento do cliente
O cliente concede consentimento, o conector guarda os tokens, e cada chamada ao banco é autorizada e registrada. Quando o consentimento expira ou é retirado, o aplicativo pede novamente ao cliente em vez de falhar em silêncio.
- Fluxo principal
- Assíncrono
- Caminho de exceção
O fluxo em 7 etapas
O fluxo, etapa a etapa
- De Cliente para O seu aplicativo ou plataforma: Concede consentimento (fluxo principal).
- De O seu aplicativo ou plataforma para Conector de open banking: Solicitações de conta e de pagamento, por REST/JSON (fluxo principal).
- De Conector de open banking para APIs bancárias ou agregador: Chamadas de API autorizadas, por OAuth 2.0 · FAPI · REST (fluxo principal).
- De APIs bancárias ou agregador para Conector de open banking: Saldos, transações e status de pagamento, por REST/JSON · webhook (assíncrono).
- De Conector de open banking para ERP ou razão: Transações normalizadas, por REST/JSON (fluxo principal).
- De APIs bancárias ou agregador para Conector de open banking: Consentimento expirado ou retirado, por HTTP 401 · 403 (caminho de exceção).
- De Conector de open banking para O seu aplicativo ou plataforma: Cliente convidado a renovar o consentimento (caminho de exceção).
Visão geral
O open banking permite que uma aplicação leia as contas de um cliente e inicie pagamentos por APIs bancárias reguladas, com o consentimento do cliente. Ele viabiliza agregação de contas, verificações de capacidade de crédito para empréstimos, checkouts de pagamento conta a conta e visões de tesouraria entre bancos.
O desenho de referência coloca um conector de open banking entre a sua aplicação e os bancos, diretamente ou por um agregador licenciado. O conector conduz a jornada de consentimento, guarda os tokens com segurança, chama as APIs dos bancos segundo padrões como o Berlin Group NextGenPSD2 ou o UK Open Banking Standard, e converte os dados de cada banco em um modelo consistente.
O consentimento não é permanente, e o desenho conta com isso. Quando o consentimento expira ou é retirado, o cliente é convidado a renová-lo, em vez de a aplicação perder dados silenciosamente. Toda chamada é autorizada, registrada e ligada ao consentimento que a permitiu.
Como o fluxo funciona
O cliente concede o consentimento
O cliente escolhe o seu banco, vê o que será compartilhado e por quanto tempo, e se autentica no banco, que o redireciona de volta à sua aplicação.
A sua aplicação solicita
A sua aplicação pede saldos, transações ou um pagamento pela API do conector, nunca diretamente ao banco.
O conector chama o banco
O conector usa os tokens armazenados para fazer chamadas autorizadas à API do banco ou ao agregador, seguindo o perfil de segurança que o banco exige.
Dados e status retornam
Saldos, transações e status de pagamento retornam como respostas ou webhooks, e o conector os normaliza em um único modelo entre bancos.
Usar os dados
As transações normalizadas alimentam o seu produto, os seus modelos de risco ou o seu ERP para posições de caixa e conciliação.
Quando algo falha
O consentimento expira ou é retirado
O banco recusa a chamada. O conector marca o consentimento como não mais válido e a sua aplicação pede ao cliente que o renove, explicando o motivo.
Um pagamento é rejeitado
O status e o motivo do banco voltam pela API ou por um webhook, e o cliente e a sua equipe de operações veem o resultado imediatamente.
Um banco limita o acesso
Os bancos limitam a frequência com que os dados podem ser buscados sem o cliente presente. O conector agenda atualizações dentro desses limites e recua quando o banco sinaliza.
Uma API bancária está indisponível
As chamadas são repetidas com intervalos crescentes, os últimos dados válidos são mostrados com a sua idade, e um alerta é gerado se a indisponibilidade continuar.
Normas e sistemas
- Normas e canais bancários
- PSD2
- Berlin Group NextGenPSD2
- UK Open Banking Standard
- FAPI
- Integração
- REST
- Webhooks
- Identidade e acesso
- OAuth 2.0
- OpenID Connect
Perguntas e respostas
Devemos conectar diretamente aos bancos ou por um agregador?
Um agregador oferece muitos bancos por uma única API e trata as diferenças de cada banco, com um custo por chamada ou por conexão. Conexões diretas dão mais controle e podem servir para um número pequeno de bancos importantes. Muitos produtos começam com um agregador e acrescentam conexões diretas depois. Comparamos as opções em relação aos bancos e países de que você precisa.
Precisamos de licença para usar open banking?
Informações de conta e iniciação de pagamento são atividades reguladas em muitos países. Ou a sua empresa detém a autorização, ou você trabalha por meio de um provedor licenciado que a detém. Qual se aplica depende do seu país e do seu caso de uso, e os seus consultores jurídicos e de conformidade devem confirmar isso. Construímos a integração para qualquer um dos caminhos que você escolher.
Como o consentimento do cliente é tratado?
O cliente vê quais dados são compartilhados, para que finalidade e por quanto tempo, e se autentica no seu próprio banco. O conector guarda o consentimento e os seus tokens criptografados, e cada chamada está ligada a um consentimento válido. Os clientes podem retirar o consentimento, e o conector deixa de chamar esse banco em nome deles quando isso acontece.
Quais bancos e países são cobertos?
A cobertura depende das regras da região e das APIs dos bancos. A União Europeia e o Reino Unido têm cobertura ampla sob a PSD2 e o UK Open Banking Standard. Em outros lugares a cobertura varia, e os agregadores preenchem parte das lacunas. Verificamos a cobertura para os bancos que os seus clientes usam antes de você se comprometer com um desenho.
O open banking substitui as conexões bancárias host-to-host?
Não para a maior parte do trabalho de tesouraria corporativa. Os canais host-to-host tratam arquivos de pagamento em lote e extratos completos das suas próprias contas. O open banking serve para produtos voltados ao cliente, saldos em tempo real e pagamentos individuais. Muitas empresas usam os dois: host-to-host para os seus próprios lotes de pagamentos e open banking para os seus clientes.
Como os dados de open banking são protegidos?
Tokens e registros de consentimento são criptografados em repouso, apenas o conector pode usá-los, e cada chamada é registrada com o consentimento por trás dela. Coletamos apenas os dados de que a finalidade precisa e definimos por quanto tempo são mantidos. Regras de proteção de dados como o GDPR se aplicam a esses dados, e projetamos junto com o seu encarregado de proteção de dados.
Comece com uma conversa, não com um contrato.
Conte o que você precisa construir, conectar ou proteger. Um arquiteto analisa com você e recomenda por onde começar.
O que acontece a seguir
Definição do horário
Nossa equipe envia um e-mail para combinar o horário da sessão.
Sessão de pré-consultoria
Uma sessão on-line gratuita de pré-consultoria de 30 minutos: analisamos os seus objetivos, sistemas e restrições.
Avaliação de prontidão
Em uma avaliação de prontidão gratuita de 48 horas, um arquiteto principal verifica o seu projeto com a Definição de Prontidão em 6 pontos e recomenda a trilha adequada.
Escolha da trilha
Projetos com escopo pronto recebem uma proposta vinculante em 3 a 5 dias úteis. Projetos em estágio de conceito começam no Blueprint Studio. Um sistema em produção com falhas, não documentado ou que precisa de integração começa com um diagnóstico de 1 a 2 semanas. O Blueprint Studio e o diagnóstico têm cada um uma taxa fixa, cotada na proposta.