APIs de open banking
Open banking: dados de conta e pagamentos por APIs bancárias
Informação 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 registada. Quando o consentimento expira ou é retirado, a aplicação 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 A sua aplicação ou plataforma: Concede consentimento (fluxo principal).
- De A sua aplicação ou plataforma para Conector de open banking: Pedidos 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 estado 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 A sua aplicação ou plataforma: Pedido ao cliente que renove 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 num 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, registada 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á partilhado e por quanto tempo, e autentica-se 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 estado retornam
Saldos, transações e estado de pagamento retornam como respostas ou webhooks, e o conector os normaliza num ú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 reconciliaçã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 estado e o motivo do banco voltam pela API ou por um webhook, e o cliente e a sua equipa 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 um 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 ligar 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 ligação. Ligações diretas dão mais controlo e podem servir para um número pequeno de bancos importantes. Muitos produtos começam com um agregador e acrescentam ligações diretas depois. Comparamos as opções frente aos bancos e países de que precisa.
Precisamos de licença para usar open banking?
Informação 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 trabalha por meio de um fornecedor 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. Construímos a integração para qualquer um dos caminhos que escolher.
Como o consentimento do cliente é tratado?
O cliente vê quais dados são partilhados, para que finalidade e por quanto tempo, e autentica-se no seu próprio banco. O conector guarda o consentimento e os seus tokens encriptados, 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 se comprometer com um desenho.
O open banking substitui as ligações bancárias host-to-host?
Não para a maior parte do trabalho de tesouraria corporativa. Os canais host-to-host tratam ficheiros de pagamento em lote e extratos completos das suas próprias contas. O open banking serve para produtos virados para o cliente, saldos em tempo real e pagamentos individuais. Muitas empresas usam os dois: host-to-host para os seus próprios lotes de pagamento e open banking para os seus clientes.
Como os dados de open banking são protegidos?
Tokens e registos de consentimento são encriptados em repouso, apenas o conector pode usá-los, e cada chamada é registada com o consentimento por trás dela. Recolhemos 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 precisa construir, ligar ou proteger. Um arquiteto analisa consigo e recomenda por onde começar.
O que acontece a seguir
Definição do horário
A nossa equipa envia um e-mail para combinar o horário da sessão.
Sessão de pré-consultoria
Uma sessão em linha gratuita de pré-consultoria de 30 minutos: analisamos os seus objetivos, sistemas e restrições.
Avaliação de prontidão
Numa 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 o percurso adequado.
Escolha do percurso
Projetos com âmbito pronto recebem uma proposta vinculante em 3–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–2 semanas. O Blueprint Studio e o diagnóstico têm cada um uma taxa fixa, cotada na proposta.