O credor que quer ver a renda real
“Os extratos em PDF que os clientes nos enviam não servem: queremos ler a conta com a permissão deles e decidir em minutos. Disseram-nos que isso já é um serviço regulado.”
Se o seu produto lê e agrega as contas bancárias dos seus usuários, você está prestando um serviço de informação sobre contas. É a porta de entrada mais barata para o mundo regulado dos pagamentos: sem capital inicial, mas com seguro de responsabilidade civil profissional e um processo perante o Banco de España que precisa ser bem construído.
Seu produto precisa de licença AISP? Respondemos em 24 h
Conte-nos quais dados você lê, de quem e para quê. Diremos se você está dentro do perímetro regulatório, se compensa ter licença própria ou operar sobre a de um terceiro, e quanto custa cada via.
Aqui não explicamos o que é open banking: para isso temos páginas específicas. Isto é o que precisa ser decidido, construído e apresentado para que sua empresa fique registrada e possa operar.
Antes de abrir um processo, vale a pena olhar o caminho curto: prestar o serviço como agente de uma instituição autorizada ou apoiar-se em um prestador que já tem o registro. Menos controle e menos margem, mas chegada ao mercado em uma fração do tempo.
Se o plano inclui movimentar dinheiro (recebimentos, transferências, carteiras), o AIS não basta e o projeto passa a ser de instituição de pagamento, com capital inicial nos valores fixados pelas normas, salvaguarda de fundos e um processo de outro porte.
Ler contas e iniciar pagamentos são dois serviços diferentes, com dois regimes diferentes. Se você também vai ordenar pagamentos a partir da conta do usuário, esta é a página para você.
Muitos projetos combinam informação sobre contas com outra atividade comercial ou financeira. Nesses casos, a estrutura societária e o perímetro da licença são definidos antes de fazer o pedido.
Depende dos serviços que você presta: o rol do artigo 2 da Lei 10/2010 precisa ser comparado com o seu modelo real antes de dar qualquer coisa como certa.
Informação sobre contas, iniciação de pagamentos, moeda eletrônica, crédito ou criptoativos: cada modelo tem sua figura e seu custo regulatório.
Quase ninguém começa querendo uma licença de pagamentos. Chega-se aqui porque o produto precisa ler a conta do usuário e alguém pergunta com que amparo legal isso é feito.
“Os extratos em PDF que os clientes nos enviam não servem: queremos ler a conta com a permissão deles e decidir em minutos. Disseram-nos que isso já é um serviço regulado.”
“Nosso valor é mostrar em uma única tela o que o usuário tem espalhado em cinco instituições. Sem acesso às contas não há produto, e o acesso exige estar registrado.”
“Queremos que o lançamento bancário entre sozinho no software e bata com a fatura. É mais uma função do nosso ERP, mas tecnicamente é informação sobre contas.”
“Aluguéis, seleção de fornecedores, cadastro de clientes: pedimos comprovantes que se falsificam em dois minutos. Ler a conta com consentimento é mais confiável e mais rápido.”
O regime do AISP é o mais acessível do mundo dos pagamentos, mas isso não o transforma em mera formalidade. Estas três falhas são as que mais custam dinheiro e meses.
Achar que pedir as credenciais ao usuário tira você do perímetro: o que define o serviço é a atividade, não o canal técnico pelo qual você acessa. Se você consolida, como serviço, informações das contas de pagamento dos seus usuários, precisa de registro, seja usando a interface do banco ou qualquer outro método.
Abrir o processo quando ainda não há produto: muitos projetos podem validar o mercado sobre a licença de um terceiro e pedir a própria quando o volume justificar. Pedir registro com uma demo e sem equipe de segurança é a forma mais cara de aprender.
Apresentar a parte de segurança e dados em branco: o processo de um AISP se decide na gestão de riscos operacionais, continuidade, controle de acessos e tratamento de dados pessoais. É justamente o que mais se resolve com dois parágrafos genéricos, e o que mais gera exigências.
| Via | O que exige de você | Quando faz sentido |
|---|---|---|
| Registro próprio como AISP | Processo perante o Banco de España: programa de atividades, governança, segurança e seguro de responsabilidade civil profissional ou garantia comparável. Não exige capital inicial. | Quando a agregação é o núcleo do seu produto, você quer controlar a relação com o usuário e prevê usar o passaporte para outros mercados. |
| Sobre a licença de um terceiro | Contrato com uma instituição autorizada, registro como agente quando for o caso e dependência operacional e reputacional do titular da licença. | Quando você precisa chegar ao mercado já, validar a demanda, ou quando o acesso às contas é acessório dentro de um produto maior. |
| Instituição de pagamento ou instituição de pagamento híbrida | Regime completo: capital inicial nos valores fixados pelas normas, salvaguarda dos fundos de clientes e estrutura de compliance muito mais pesada. | Quando, além de ler contas, você vai iniciar pagamentos, receber por conta de terceiros ou manter fundos de usuários. |
Analisamos seu produto, os dados que você precisa ler e seu calendário comercial, e dizemos qual das três vias é melhor para você. Se for o caso de registro próprio, preparamos o processo completo perante o Banco de España: programa de atividades, governança, seguro, segurança e proteção de dados.
Ficha legal · Verificado no BOE e no registro do Banco de España em 5 de novembro de 2026
O prestador de serviços de informação sobre contas não é autorizado: é registrado. Isto é o que a norma estabelece:
Parte da documentação exigida de uma instituição de pagamento (art. 3.1 do RD 736/2019, que remete ao art. 2.1), entre outros: programa de atividades, plano de negócios, governança corporativa e controle interno, continuidade do negócio e política de segurança.
A instituição deve ter sua administração central, sua sede e parte de sua atividade na Espanha (art. 15.2 do RDL 19/2018).
Se você também quer iniciar pagamentos, precisa de autorização como PISP, com 50.000 euros de capital. Compare todas as figuras em as licenças do Banco de España.
Em 5 de novembro de 2026, o registro de entidades do Banco de España inclui 5 instituições espanholas prestadoras do serviço de informação sobre contas.
De registro. O AISP é inscrito no registro especial do Banco de España e é tratado como instituição de pagamento, mas sem a autorização nem o capital que esta exige (art. 15 do RDL 19/2018). Em contrapartida, o seguro de RC é obrigatório (art. 16.2).
Fontes: RDL 19/2018 (arts. 15, 16 e 19), RD 736/2019 (arts. 1, 2 e 3), Registro de entidades do Banco de España (dados de 5 de novembro de 2026).
Um AISP é o prestador autorizado a prestar o serviço de informação sobre contas: acessar, com o consentimento do usuário, os dados das suas contas de pagamento e apresentá-los de forma consolidada. Não movimenta dinheiro, não ordena pagamentos e não mantém fundos de clientes.
Se você quer entender o marco geral (o que é open banking ou o que a PSD2 introduziu), temos páginas dedicadas: open banking e PSD2. Esta página trata de outra coisa: do processo que transforma sua empresa em um AISP registrado.
Nenhum. É o dado que surpreende quase todos os projetos: o regime dos prestadores de serviços de informação sobre contas não exige capital inicial. Em contrapartida, exige sim um seguro de responsabilidade civil profissional ou uma garantia comparável que cubra a responsabilidade perante os bancos e perante os usuários.
Isso não significa que o projeto seja de graça: é preciso sustentar estrutura, segurança, compliance e auditoria. Mas a barreira de entrada é incomparavelmente mais baixa que a de uma instituição de pagamento.
Em muitos casos, sim, e é a primeira pergunta que fazemos. Há duas vias habituais: prestar o serviço como agente de uma instituição autorizada ou construir seu produto sobre um prestador que já tem o registro e fornece o acesso às contas.
Nenhuma das duas libera você de tudo: você assina um contrato com obrigações, depende da licença alheia e o tratamento de dados continua sendo responsabilidade sua. Mas elas permitem validar o mercado sem abrir um processo. Vale a pena revisar também as exclusões do regime de serviços de pagamento antes de assumir que você está dentro.
As normas fixam três meses a partir do momento em que o pedido está completo e, se não houver resposta, ele se considera indeferido (arts. 1.2 e 3.2 do RD 736/2019). O que define o calendário real é outra coisa. Um processo completo, com a documentação de segurança e de proteção de dados feita de verdade, avança; um que chega pela metade entra em uma roda de exigências que pode durar mais do que toda a preparação.
O que podemos antecipar é o que perguntam e em que ordem. É essa parte que encurta o calendário: chegar com as respostas escritas antes que as perguntas sejam feitas.
Só se você for ordenar pagamentos a partir da conta do usuário. Ler e agregar informações é um serviço; iniciar uma transferência é outro, com regime próprio (este sim com requisitos de capital e de seguro), que explicamos em serviço de iniciação de pagamentos.
Muitos projetos começam pelo AIS, comprovam que o usuário responde e acrescentam o PIS depois. Se você já sabe que vai acabar chegando lá, vale a pena desenhar o programa de atividades e a estrutura pensando na ampliação, e não em um remendo posterior.
É preciso verificar caso a caso, sem dar nada por certo em nenhuma direção. O rol de sujeitos obrigados está no artigo 2 da Lei 10/2010 e sua aplicação depende dos serviços que você realmente presta: um projeto que só consolida informações não está na mesma posição que um que combina agregação com outros serviços de pagamento ou financeiros.
O que convém ter claro desde o desenho é o conheça seu cliente (KYC) e a rastreabilidade dos acessos. Analisamos isso com você junto com nosso serviço de PLD/FT.
É metade do processo e onde mais projetos ficam aquém. O acesso se baseia em um consentimento explícito e limitado à finalidade concreta que o usuário aceitou: você não pode reutilizar esses dados para outros fins nem conservá-los além do necessário.
Isso obriga a desenhar minimização, prazos de conservação, controle de acessos internos, criptografia, registro das atividades de tratamento e avaliação de impacto quando for o caso. O supervisor de pagamentos pergunta sobre isso e, além disso, há o regulador de dados por trás: trabalhamos esse ponto junto com nosso serviço de proteção de dados.
Então você tem uma camada a mais de regulação. A avaliação de solvência e o credit scoring de pessoas físicas são um caso de alto risco do AI Act (Regulamento (UE) 2024/1689), cujo grosso das obrigações para sistemas de alto risco se aplica a partir de agosto de 2026.
Traduzindo para o seu projeto: governança do modelo, qualidade dos dados, documentação técnica, supervisão humana e rastreabilidade das decisões. É perfeitamente compatível com um AISP bem estruturado, mas é preciso desenhá-lo desde o início. Explicamos isso em AI Act.
Sim. O pacote PSD3/PSR, proposto pela Comissão em junho de 2023, continua em tramitação, e o regulamento de open finance (FIDA) está em negociação. Nenhum dos dois elimina o registro: eles tendem a reorganizar interfaces, responsabilidades e acesso a dados para além dos pagamentos.
Quem já estiver registrado chegará com estrutura, contratos e controles prontos; quem esperar começará do zero quando o mercado já tiver se movido. Acompanhamos os dois processos legislativos em PSD3 e FIDA.
Um processo de AISP é curto em comparação com o de uma instituição de pagamento, mas é avaliado com a mesma lupa no que importa: governança, segurança e dados. Este é o caminho.
Analisamos quais dados você lê, de quem, com que consentimento e para quê. Daí sai se você precisa de registro próprio, se compensa operar sobre um terceiro ou se o seu caso se enquadra em alguma exclusão do regime de serviços de pagamento.
Programa de atividades, estrutura societária e idoneidade, seguro de responsabilidade civil profissional, política de segurança e gestão de riscos operacionais, continuidade, terceirização e proteção de dados. Tudo coerente entre si.
Certificados e conexão às interfaces das instituições, contratos com usuários e com fornecedores, gestão de incidentes, reporting ao supervisor e revisão periódica de seguros, políticas e controles.
Se o seu modelo também vai movimentar dinheiro, olhe antes a licença de instituição de pagamento ou a fórmula de instituição de pagamento híbrida, porque a estrutura societária muda.
Termos que você vai ler no pedido, nos contratos com os bancos e nas exigências. Usá-los com precisão evita semanas de mal-entendidos.
Instituição registrada para acessar, com o consentimento do usuário, as informações das suas contas de pagamento e apresentá-las de forma consolidada.
Serviço de informação sobre contas: a atividade regulada que dá origem ao registro. É definido pelo que você faz, não pela tecnologia que usa.
Prestador de serviços de pagamento que gere a conta: a instituição que deve permitir o acesso às informações quando o usuário autoriza.
Mecanismo pelo qual o usuário se autentica perante seu banco para autorizar o acesso, com os elementos independentes que as normas exigem.
Canal que as instituições disponibilizam aos prestadores registrados, com seus requisitos de disponibilidade, desempenho e mecanismos alternativos.
Cobertura (ou garantia comparável) que responde perante as instituições que gerem as contas e perante os usuários pela atividade do prestador.
Autorização explícita do usuário, limitada à finalidade concreta aceita, revogável e documentada com evidência de quando e como foi obtida.
Inscrição pública que comprova que você está habilitado. Os bancos a consultam antes de dar acesso a você, e seus clientes também deveriam consultá-la.
O marco europeu permite estender a atividade a outros países da UE mediante notificação por meio do seu supervisor, nos termos fixados pelas normas.
Descrição precisa de quais informações são lidas, de quais contas, com que finalidade e com que jornada do usuário, sem ambiguidades sobre o alcance do serviço.
Memorial do serviço com fluxos de dados e telas, diagramas de arquitetura, termos de uso do usuário e descrição dos meios técnicos e humanos.
Sociedade constituída com quadro acionário transparente e órgão de administração com honorabilidade e capacidade para dirigir uma instituição supervisionada.
Escritura e estatuto social, quadro de sócios e beneficiários finais, questionários de idoneidade, currículos documentados e certidões de antecedentes criminais.
Cobertura ou garantia comparável proporcional ao perfil de risco, ao volume previsto e aos mercados em que você vai operar.
Apólice ou compromisso firme da seguradora com alcance e exclusões, cálculo justificativo do valor e evidência de renovação periódica.
Gestão documentada dos riscos operacionais e de segurança, controle de acessos, criptografia, gestão de incidentes e capacidade de continuar operando diante de uma queda.
Política de segurança aprovada, análise de riscos, procedimento de incidentes com canais de comunicação, plano de continuidade e testes realizados.
Tratamento limitado à finalidade consentida, com minimização e conservação delimitada, e fornecedores críticos sob controle contratual efetivo.
Registro das atividades de tratamento, textos de consentimento e evidência de sua obtenção, avaliação de impacto quando for o caso e contratos com fornecedores e operadores.
Se você se reconhece em algum deles, vale a pena parar e validar o enquadramento antes de se conectar ao primeiro banco.
Esta página trata de uma coisa concreta: o processo de autorização e registro do AISP perante o Banco de España. Se o que você precisa é entender o marco geral (o que é open banking, o que a PSD2 introduziu, o que vai mudar com a PSD3 ou até onde o acesso a dados financeiros vai chegar com o FIDA), há páginas dedicadas a cada tema, e elas vão servir melhor do que este texto.
O modelo de acesso a dados e a contas que tornou possível esta figura, explicado do zero e sem o jargão dos processos.
A Diretiva (UE) 2015/2366 e sua transposição na Espanha pelo RD-lei 19/2018, com seus serviços, sujeitos e obrigações.
O pacote proposto em junho de 2023 continua em tramitação: o que está sendo negociado e o que vale a pena antecipar no seu desenho.
O acesso a dados de investimentos, seguros e previdência que está sendo negociado agora mesmo, e como isso afeta quem já agrega contas.
E se o que você quer é começar, a ordem importa: compare antes a via do agente de uma instituição de pagamento com o registro próprio, verifique se o seu caso se enquadra em alguma exclusão do regime de serviços de pagamento e consulte o mapa de licenças fintech para situar seu projeto.
Conte-nos como seu produto funciona e o que você faz com os dados das contas dos seus usuários. Diremos se você precisa de registro próprio e por onde começar.
Última atualização: 4 de agosto de 2026
O prestador de serviços de informação sobre contas (AISP) é a figura que permite acessar, com o consentimento prévio do usuário, as informações das suas contas de pagamento para apresentá-las de forma consolidada. Seu marco é a PSD2 (Diretiva (UE) 2015/2366) e, na Espanha, o RD-lei 19/2018, e o registro cabe ao Banco de España. Este texto não explica o open banking (para isso você tem nossa página de open banking e a de PSD2): aqui explicamos como o processo é construído.
O dado que quase ninguém conhece e que muda muitos planos de negócios: o regime do prestador de serviços de informação sobre contas não exige capital inicial. Em contrapartida, exige um seguro de responsabilidade civil profissional ou uma garantia comparável que responda perante as instituições que gerem as contas e perante os usuários pelos danos decorrentes da sua atividade. Só essa diferença separa dois mundos: a instituição de pagamento começa com capital nos valores fixados pelas normas e com a obrigação de salvaguardar os fundos de clientes, enquanto o AISP pode ser montado com uma estrutura muito mais leve, porque nunca toca no dinheiro. O que ele compartilha com as demais instituições supervisionadas é a exigência qualitativa: governança, gestão de riscos, segurança, continuidade e controle de fornecedores. Aí não há regime simplificado que valha. Por isso, o erro mais frequente nesses projetos não é subestimar o capital (não há), mas subestimar o custo de sustentar uma instituição supervisionada: apólices que se renovam, políticas que se revisam, incidentes que se comunicam e auditorias que se enfrentam. Nosso trabalho começa justamente aí, colocando números e calendário nesse custo antes que você decida se quer registro próprio ou prefere se apoiar na licença de um terceiro enquanto valida o produto.
Um processo de AISP é mais curto que o de uma instituição de pagamento, mas é lido com a mesma exigência no que realmente importa. O primeiro bloco é o programa de atividades: quais informações você vai ler, de quais contas, com que finalidade, com que jornada do usuário e com que arquitetura técnica. Ele precisa ser tão concreto que qualquer pessoa consiga desenhar o fluxo de dados só de lê-lo. O segundo é a estrutura: sociedade, sócios, beneficiários finais e órgão de administração, com a honorabilidade e a capacidade de quem vai dirigir uma instituição supervisionada. O terceiro, o seguro de responsabilidade civil profissional ou a garantia comparável, com um alcance justificado em relação ao seu volume e aos mercados onde você vai operar. O quarto (o que mais gera exigências) é o pacote de segurança e riscos operacionais: controle de acessos, criptografia, gestão de incidentes, plano de continuidade e testes feitos, não prometidos. E o quinto é o de dados pessoais e fornecedores: consentimento explícito e granular, minimização, conservação delimitada e contratos de terceirização com os terceiros que sustentam sua conexão. Cinco blocos que devem contar a mesma história: quando o programa de atividades diz uma coisa e a política de segurança diz outra, a exigência chega sozinha.
Preferimos perder um trabalho a vender a você um processo de que você não precisa. Há pelo menos três situações em que um projeto de agregação pode chegar ao mercado sem registro próprio. A primeira: operar como agente de uma instituição autorizada, com contrato, registro quando for o caso e o guarda-chuva da licença dela. A segunda: construir seu produto sobre um prestador já registrado que fornece o acesso às contas enquanto você fornece a camada de valor; você perde margem e controle da relação técnica, mas ganha meses. A terceira: verificar se o seu caso se enquadra em alguma exclusão do regime de serviços de pagamento, que existem e às vezes resolvem o problema por inteiro. Nenhuma das três é de graça: você continua respondendo pelo tratamento de dados, pelo contrato com seu usuário e pela sua própria segurança, e nas duas primeiras aceita também condições econômicas e operacionais que não controla (tarifa por consulta, cobertura de bancos, qualidade do serviço e prioridade em relação a outros clientes do prestador). E nenhuma é para sempre: quando a agregação passa a ser o núcleo do negócio, depender da licença de outro se torna um risco estratégico (mudanças de preço, de condições ou de dono) e o registro próprio deixa de ser um custo para ser um ativo. Essa transição deve ser planejada, não improvisada.
O marco está se movendo em duas frentes. O pacote PSD3/PSR, proposto pela Comissão em junho de 2023, continua em tramitação e tende a reorganizar o acesso às contas, as interfaces e a divisão de responsabilidades entre bancos e prestadores. E o regulamento de acesso a dados financeiros (o FIDA, proposto em junho de 2023 e também em negociação) quer levar o modelo além dos pagamentos, para investimentos, seguros e previdência, por meio de prestadores autorizados e esquemas de compartilhamento de dados. Nenhum dos dois elimina a figura nem o registro; ambos elevam o nível de exigência em governança, segurança e contratos. A conclusão prática é o contrário da intuitiva: quem se registra agora chega a esse cenário com a instituição constituída, controles testados na prática e relação com o supervisor, e adaptar-se custará uma revisão; quem espera começará do zero quando o mercado já tiver sido dividido. Some-se a isso o restante do perímetro que um projeto de dados financeiros traz consigo: proteção de dados, resiliência operacional e, se você decide com modelos automatizados, o AI Act. Organizar tudo desde o desenho custa uma fração do que custa reconstruir depois, quando você já tem usuários, contratos assinados com instituições que gerem as contas e um supervisor que pergunta por escrito. Nossa recomendação, quando o negócio já está validado, é não esperar pela norma perfeita: registrar-se com o marco vigente e deixar o processo preparado para absorver o que vier.
Este conteúdo tem caráter informativo e não constitui assessoria jurídica. As normas citadas podem ter sido modificadas após a data de atualização indicada: verifique sempre a versão vigente ou fale conosco para analisar o seu caso concreto.
Normas de referência, com link para o texto oficial:
Normas e links revisados em .