2.6.2 - Taxa de Conversão - v2.0.

2.6.2 - Taxa de Conversão - v2.0.

1. Controle de Versão

Versão

Data

Resumo das Alterações

Versão

Data

Resumo das Alterações

1 

09/06/2026 

Versão inicial – compilação das três taxas (Dados, Pagamentos e Vínculo), fontes informacionais (Planilha e PCM) e estados de conformidade (Conforme, Tolerância e Diagnóstico) 

2 

13/07/2026 

Ajustes metodológicos em Pagamentos, alinhados com o BACEN: (i) remoção dos fluxos sem redirecionamento (FIDO Flow / JSR) do cálculo; (ii) adição dos Pagamentos Automáticos via PCM, com cálculo por média ponderada entre com redirecionamento e Automáticos. 

2. Introdução e Objetivos

Esta métrica tem como propósito monitorar a eficiência das jornadas de compartilhamento de dados, iniciação de pagamentos e criação de vínculo dentro do ecossistema do Open Finance. O objetivo é assegurar padrões de conversão adequados, refletindo a qualidade e a eficácia dessas jornadas na facilitação de operações seguras e eficientes entre as instituições participantes e seus clientes.

O painel nasce com a metodologia vigente calculada retroativamente, de forma a assegurar a comparabilidade da série histórica, considerando as alterações metodológicas comunicadas por meio do Informa [Open Finance] Informa #908.

Nenhuma métrica apresentada neste painel utiliza os dados de instituições marcadas como ambiente de teste (FVP). As instituições desconsideradas correspondem aos seguintes orgid's:

  • d7384bd0-842f-43c5-be02-9d2b2d5efc2c

  • 1dbfe32a-5f1e-4841-a30c-9f1b5f24ad36

  • b2a8233c-eda6-4c46-8263-813d71508f1b

3. Sobre a Métrica

Esta métrica foca em três produtos, cada um representando uma jornada distinta para o cliente. As três métricas são comparadas a partir de uma meta calculada a partir da performance do ecossistema.

I. Compartilhamento de dados: A Taxa de Criação de Consentimento de Dados de Clientes é calculada com base na proporção de consentimentos autorizados com sucesso em relação ao número de solicitações válidas de criação de consentimentos, direcionadas para a instituição transmissora de dados.

II. Iniciação de Transação de Pagamento: A Taxa de Criação de Consentimento de Pagamentos é calculada com base na proporção de consentimentos autorizados com sucesso em relação ao número de solicitações válidas de criação de consentimentos, direcionadas para a instituição detentora.

III. Vínculo: A Taxa de Criação de Vínculo é calculada pela quantidade de vínculos autorizados em relação ao volume de solicitações válidas de criação de vínculo, direcionadas para a instituição detentora de conta.

3.1. Fontes informacionais

A apuração das taxas utiliza duas fontes informacionais distintas, a depender do produto e do conglomerado da instituição participante: 

  • Planilha autoreportada: arquivos enviados diretamente pelas próprias instituições, contendo os volumes apurados internamente de solicitações e autorizações. 

  • PCM (Plataforma de Coleta de Métricas): plataforma centralizada da Estrutura de Governança do Open Finance que coleta as métricas a partir das chamadas de API entre os participantes. 

Para os produtos de Dados de Clientes e de Pagamento com Redirecionamento, a fonte informacional adotada na apuração da taxa varia conforme o conglomerado: os 19 maiores conglomerados* são monitorados pela Planilha autoreportada, enquanto os demais pela PCM.  

O cálculo da meta para Dados de Clientes, contudo, é realizado exclusivamente a partir das Planilhas autoreportadas, tomando como base as taxas dos conglomerados que dispõem dessa fonte. 

No produto Pagamentos, a taxa é composta pela média ponderada entre Pagamentos com redirecionamento e Pagamentos Automáticos (Pix Automático e Transferências Inteligentes), tendo como peso o volume de solicitações de consentimento válidas (Detalhado na seção 5.2.1). Os Pagamentos com redirecionamento seguem a regra geral (Planilha para os 19 maiores conglomerados, PCM para os demais), enquanto os Pagamentos Automáticos são apurados integralmente via PCM, independentemente do conglomerado. 

Ainda para Pagamentos, ficam excluídos do cálculo os fluxos sem redirecionamento (FIDO Flow / JSR), tanto na apuração via PCM quanto via Planilha, considerando-se exclusivamente pagamentos com redirecionamento. Adicionalmente, na apuração via PCM, são considerados como sucesso não apenas os consentimentos reportados como autorizados, mas também aqueles efetivamente utilizados pelo client em APIs de consumo, garantindo que a métrica reflita o uso real do consentimento. 

Para o produto Vínculo, tanto a apuração da taxa quanto o cálculo da meta são realizados integralmente via PCM, sem uso de Planilhas autoreportadas, independentemente do conglomerado. 

Segue abaixo um quadro consolidado das fontes informacionais.

Item monitorado 

Produto 

Conglomerado 

Fonte da Taxa 

Fonte da Meta 

 

Compartilhamento de dados 

Dados de Clientes 

19 conglomerados 

Planilha 

Planilha 

Dados de Clientes 

Demais conglomerados 

PCM 

Planilha 

 

 

 

 

Iniciação de Transação de Pagamento 

Pagamentos com redirecionamento

19 conglomerados 

Planilha 

Planilha 

Pagamentos com redirecionamento

Demais conglomerados 

PCM 

Planilha 

Pagamentos Automáticos 

19 conglomerados 

PCM 

PCM 

Pagamentos Automáticos 

Demais conglomerados 

PCM 

PCM 

Vínculo 

Vínculo 

Todos os conglomerados 

PCM 

PCM 

*19 maiores conglomerados: BMG, BTG, Banco do Brasil, Bradesco, C6, Caixa, Digio, Inter, Itaú, Mercado Pago, Neon, Nubank, PagBank, Pan, PicPay, Santander, Sicoob, Sicredi, XP

3.2. Identificação dos produtos

A separação dos produtos é realizada com base no método HTTP POST e nos respectivos endpoints.

Os endpoints utilizados para identificar cada produto são apresentados na tabela a seguir.

Produto 

Endpoint

Dados de Clientes 

Endpoints cujo caminho termina em /consents

 

Pagamentos com redirecionamento

/open-banking/payments/v4/consents

/open-banking/payments/v5/consents

Observação: Até o fechamento de julho/2026, era considerado exclusivamente o endpoint /open-banking/payments/v4/consents. A partir dos fechamentos seguintes, o endpoint /open-banking/payments/v5/consents também passou a ser considerado.

Pix automático

/open-banking/automatic-payments/v2/recurring-consents 

Transferências Inteligentes

/open-banking/automatic-payments/v2/recurring-consents

Pagamento sem Redirecionamento/ Vínculo 

/open-banking/enrollments/v2/enrollments

Critério de diferenciação entre Pix Automático e Transferências Inteligentes: embora ambos os produtos utilizem o mesmo endpoint, a identificação é realizada por meio do campo additionalInfo_paymentType apenas para clients. Quando o campo assume o valor AUTOMATIC, a operação é classificada como Pix Automático. Quando o campo está nulo ou preenchido com SWEEPING, a operação é classificada como Transferências Inteligentes.

4. Total de Solicitações de Criação de Consentimentos

O Total de Solicitações de Consentimento representa a volumetria de intenções de consentimento registradas via API antes de qualquer ação direta de autenticação pelo cliente final no ambiente da instituição financeira.

Para operacionalizar o cálculo do total de solicitações de consentimentos, apresentamos a seguir a lógica de códigos aplicável a cada produto:

-- as colunas que começam com "is_" são flags criadas ao longo do processo para validação. where 1=1 and ts_to_date_gmt between init_date and end_date -- seção "período de apuração" and is_fvp = 0 --> is_fvp é uma flag que indica se o orgid é do teste de fvp ou não (descrito na introdução deste documento) and clientorgid <> serverorgid -- tratamento de possíveis erros. and httpmethod = 'POST' and endpoint = '/open-banking/consents/v3/consents' -- endpoint específico para dados de clientes and orgid = clientorgid
-- as colunas que começam com "is_" são flags criadas ao longo do processo para validação. where 1=1 and ts_to_date_gmt between init_date and end_date -- seção "período de apuração" and is_fvp = 0 --> is_fvp é uma flag que indica se o orgid é do teste de fvp ou não (descrito na introdução deste documento) and clientorgid <> serverorgid -- tratamento de possíveis erros. and httpmethod = 'POST' and endpoint = '/open-banking/enrollments/v2/enrollments' -- endpoint específico para vínculo and orgid = clientorgid
-- as colunas que começam com "is_" são flags criadas ao longo do processo para validação. where 1=1 and ts_to_date_gmt between init_date and end_date -- seção "período de apuração" and is_fvp = 0 --> is_fvp é uma flag que indica se o orgid é do teste de fvp ou não (descrito na introdução deste documento) and clientorgid <> serverorgid -- tratamento de possíveis erros. and httpmethod = 'POST' and (endpoint = '/open-banking/payments/v4/consents' or endpoint = '/open-banking/payments/v5/consents') -- endpoint específico para pagamentos and ( coalesce(additionalinfo_authorisationflowintent, additionalinfo_authorisationflow) <> 'fido_flow' or coalesce(additionalinfo_authorisationflowintent, additionalinfo_authorisationflow) is null ) -- additionalinfo específico para pagamentos and orgid = clientorgid
-- as colunas que começam com "is_" são flags criadas ao longo do processo para validação. where 1=1 and ts_to_date_gmt between init_date and end_date -- seção "período de apuração" and is_fvp = 0 --> is_fvp é uma flag que indica se o orgid é do teste de fvp ou não (descrito na introdução deste documento) and clientorgid <> serverorgid -- tratamento de possíveis erros. and httpmethod = 'POST' and endpoint like '%/automatic-payments/v2/recurring-consents' -- endpoint específico para pix and additionalinfo_paymenttype = 'AUTOMATIC' --additionalinfo específico para pix and orgid = clientorgid
-- as colunas que começam com "is_" são flags criadas ao longo do processo para validação. where 1=1 and ts_to_date_gmt between init_date and end_date -- seção "período de apuração" and is_fvp = 0 --> is_fvp é uma flag que indica se o orgid é do teste de fvp ou não (descrito na introdução deste documento) and clientorgid <> serverorgid -- tratamento de possíveis erros. and httpmethod = 'POST' and endpoint like '%/automatic-payments/v2/recurring-consents' and (additionalinfo_paymenttype = 'SWEEPING' or additionalinfo_paymenttype is null) and orgid = clientorgid

5. Cálculo da Taxa de Conversão

TAXA DE CONVERSÃO = ( QTD DE CONSENTIMENTOS AUTORIZADOS ) / ( QTD DE SOLICITAÇÕES DE CONSENTIMENTO VÁLIDAS )

A Taxa de Conversão também pode ser obtida por meio da análise do funil de conversão (detalhado na seção 9.5.) disponível no painel de produtos, utilizando as etapas do funil na relação a seguir.

TAXA DE CONVERSÃO = Consentimentos autorizados / (Consentimentos não autorizados visão negócio e /token + Consentimentos autorizados)

5.1. Período de apuração

Antes de detalhar o numerador e o denominador da taxa, é necessário definir o critério de apuração temporal do indicador. As taxas são calculadas mensalmente, com base em ciclos semanais que se iniciam aos sábados e encerram-se às sextas-feiras. Para fins de consolidação, uma semana pertence ao mês de referência quando a sua respectiva sexta-feira estiver contida dentro daquele mês. Na prática, a apuração de junho/2026, por exemplo, não considera o mês exato (01/06/2026 a 30/06/2026), mas o ciclo operacional compreendido entre 30/05/2026 e 26/06/2026.

Definição das semanas de um mês de referência: Maio: semana 1 (25/04 a 01/05), semana 2 (02/05 a 08/05), semana 3 (09/05 a 15/05), semana 4 (16/05 a 22/05) e semana 5 (23/05 a 29/05). Junho: semana 1 (30/05 a 05/06), semana 2 (06/06 a 12/06), semana 3 (13/06 a 19/06) e semana 4 (20/06 a 26/06). Demais dias de Junho (27-30) entram para a referência de Julho 

5.2. Fonte PCM

5.2.1. Denominador: Quantidade de solicitações de consentimentos válidas

O denominador da taxa de conversão aplica critérios obrigatórios de exclusão, independentes do produto. Esses critérios garantem que somente as jornadas válidas reportadas por ambas as pontas, processadas com sucesso e originadas por clientes legítimos da instituição sejam computadas no cálculo.

Regra Descrição StatusCode diferente de 2xx Somente são computadas as solicitações cujo statuscode HTTP pertence à família 2xx (200, 201, 204 e demais), indicando que a requisição foi processada com sucesso pela instituição. Requisições cujo statuscode pertence às famílias 4xx (erros de cliente), 5xx (erros de servidor) ou demais respostas fora da faixa de sucesso são excluídas do denominador, pois indicam falhas técnicas, autorizações inválidas ou indisponibilidade que não representam uma jornada efetiva do cliente. Chamadas não pareadas (client e server) São excluídas do denominador as chamadas que não apresentam pareamento entre as pontas client (instituição iniciadora ou receptora) e server (instituição transmissora ou detentora de conta). O pareamento exige que ambas as instituições envolvidas na jornada reportem o mesmo evento para garantir a integridade da informação. Quando apenas uma das pontas reporta a ocorrência — seja por falha no envio, descarte da informação ou indisponibilidade temporária — a chamada é considerada não pareada e não entra no cálculo. Identificadores (ID’s) nulos Para garantir a rastreabilidade e a integridade da jornada, são desconsiderados do denominador os registros sem a devida identificação de consentimento. Essa exclusão é aplicada removendo todas as requisições em que o campo ADDITIONALINFO_CONSENTID é nulo Exclusão de não clientes (DropReason) Excluem-se do denominador as ocorrências em que o CPF/CNPJ redirecionado não é cliente da instituição, identificadas por meio do campo DropReason. São computadas apenas as ocorrências cujo DropReason (ADDITIONALINFO_DROPREASON) é igual a NONE ou NULL, conforme tabela abaixo: DropReason Descrição Inclui no Denominador? NONE Cliente válido da instituição (sem descarte) ✅  Sim NULL Informação não reportada (tratado como cliente válido) ✅  Sim Outro valor Não cliente (CPF/CNPJ sem vínculo com a instituição) ❌  Não

Para operacionalizar o cálculo do denominador, apresentamos a seguir a lógica de códigos aplicável a cada produto:

-- as colunas que começam com "is_" são flags criadas ao longo do processo para validação. where 1=1 and ts_to_date_gmt between init_date and end_date --> seção "período de apuração" and is_fvp = 0 --> is_fvp é uma flag que indica se o orgid é do teste de fvp ou não (descrito na introdução deste documento) and clientorgid <> serverorgid -- tratamento de possíveis erros. and httpmethod = 'POST' and endpoint = '/open-banking/consents/v3/consents' -- endpoint específico para dados de clientes and orgid = clientorgid and statuscode like '2%' -- seção "critérios de exclusão do denominador (solicitações válidas)" and is_unpaired_server = 0 -- seção "critérios de exclusão do denominador (solicitações válidas)" and ( additionalinfo_dropreason = 'NONE' or additionalinfo_dropreason is null ) -- seção "critérios de exclusão do denominador (solicitações válidas)" and additionalinfo_consentid is not null
-- as colunas que começam com "is_" são flags criadas ao longo do processo para validação. where 1=1 and ts_to_date_gmt between init_date and end_date --> seção "período de apuração" and is_fvp = 0 --> is_fvp é uma flag que indica se o orgid é do teste de fvp ou não (descrito na introdução deste documento) and clientorgid <> serverorgid -- tratamento de possíveis erros. and httpmethod = 'POST' and endpoint = '/open-banking/enrollments/v2/enrollments' -- endpoint específico para vínculo and orgid = clientorgid and statuscode like '2%' -- seção "critérios de exclusão do denominador (solicitações válidas)" and is_unpaired_server = 0 -- seção "critérios de exclusão do denominador (solicitações válidas)" and ( additionalinfo_dropreason = 'NONE' or additionalinfo_dropreason is null ) -- seção "critérios de exclusão do denominador (solicitações válidas)" and additionalinfo_enrollmentid is not null    
-- as colunas que começam com "is_" são flags criadas ao longo do processo para validação. where 1=1 and ts_to_date_gmt between init_date and end_date -- seção "período de apuração" and is_fvp = 0 --> is_fvp é uma flag que indica se o orgid é do teste de fvp ou não (descrito na introdução deste documento) and clientorgid <> serverorgid -- tratamento de possíveis erros. and httpmethod = 'POST' and (endpoint = '/open-banking/payments/v4/consents' or endpoint = '/open-banking/payments/v5/consents') -- endpoint específico para pagamentos and ( coalesce(additionalinfo_authorisationflowintent, additionalinfo_authorisationflow) <> 'fido_flow' or coalesce(additionalinfo_authorisationflowintent, additionalinfo_authorisationflow) is null ) -- additionalinfo específico para pagamentos and orgid = clientorgid and statuscode like '2%' -- seção "critérios de exclusão do denominador (solicitações válidas)" and is_unpaired_server = 0 -- seção "critérios de exclusão do denominador (solicitações válidas)" and ( additionalinfo_dropreason = 'NONE' or additionalinfo_dropreason is null ) -- seção "critérios de exclusão do denominador (solicitações válidas)" and additionalinfo_consentid is not null
-- as colunas que começam com "is_" são flags criadas ao longo do processo para validação. where 1=1 and ts_to_date_gmt between init_date and end_date -- seção "período de apuração" and is_fvp = 0 --> is_fvp é uma flag que indica se o orgid é do teste de fvp ou não (descrito na introdução deste documento) and clientorgid <> serverorgid -- tratamento de possíveis erros. and httpmethod = 'POST' and endpoint like '%/automatic-payments/v2/recurring-consents' -- endpoint específico para pix and additionalinfo_paymenttype = 'AUTOMATIC' --additionalinfo específico para pix and orgid = clientorgid and statuscode like '2%' -- seção "critérios de exclusão do denominador (solicitações válidas)" and is_unpaired_server = 0 -- seção "critérios de exclusão do denominador (solicitações válidas)" and ( additionalinfo_dropreason = 'NONE' or additionalinfo_dropreason is null ) -- seção "critérios de exclusão do denominador (solicitações válidas)" and coalesce(additionalinfo_recurringconsentid, additionalinfo_consentid) is not null
-- as colunas que começam com "is_" são flags criadas ao longo do processo para validação. where 1=1 and ts_to_date_gmt between init_date and end_date -- seção "período de apuração" and is_fvp = 0 --> is_fvp é uma flag que indica se o orgid é do teste de fvp ou não (descrito na introdução deste documento) and clientorgid <> serverorgid -- tratamento de possíveis erros. and httpmethod = 'POST' and endpoint like '%/automatic-payments/v2/recurring-consents' and (additionalinfo_paymenttype = 'SWEEPING' or additionalinfo_paymenttype is null) and orgid = clientorgid and statuscode like '2%' -- seção "critérios de exclusão do denominador (solicitações válidas)" and is_unpaired_server = 0 -- seção "critérios de exclusão do denominador (solicitações válidas)" and ( additionalinfo_dropreason = 'NONE' or additionalinfo_dropreason is null ) -- seção "critérios de exclusão do denominador (solicitações válidas)" and coalesce(additionalinfo_recurringconsentid, additionalinfo_consentid) is not null

O denominador da Taxa de Conversão também pode ser obtido por meio da análise do funil de conversão (detalhado na seção 9.5.) disponível no painel de produtos, somando as solicitações de consentimento das etapas “Consentimentos não autorizados visão negócio e /token” e “Consentimentos autorizados”.

5.2.2. Numerador: Quantidade de consentimentos autorizados

A identificação do volume de consentimentos autorizados para composição do numerador adota uma abordagem combinada de duas fontes (com exceção de vínculo, que usa apenas APIs de negócio):

  • a) Endpoint /token (Base de Segurança): Registra os consentIds autorizados capturados diretamente na camada de segurança. Como essa base não contém a totalidade das ocorrências autorizadas, faz-se necessária a complementação via item b.

  • b) Visão Negócio (APIs de Negócio): Identifica os consentimentos consumidos e registrados nas APIs de negócio, garantindo a captura integral dos consentimentos autorizados.

Para operacionalizar o cálculo do numerador, apresentamos a seguir a lógica de códigos aplicável a cada produto:

-- as colunas que começam com "is_" são flags criadas ao longo do processo para validação. with security as ------ busca security ( select ... from where 1=1 and ts_to_date_gmt between init_date and end_date and httpmethod = 'POST' and is_fvp = 0 --> is_fvp é uma flag que indica se o orgid é do teste de fvp ou não (descrito na introdução deste documento) and clientorgid <> serverorgid and additionalinfo_consentid is not null and statuscode like '2%' and organisationid = clientorgid and is_in_denominador = 1 --> consentid's que estão no denominador da taxa and endpoint = '/token' and additionalinfo_granttype = 'AUTHORIZATION_CODE' ), apis_negocio as ---- busca por uso de negócio ( select ... from where 1=1 and ts_to_date_gmt between init_date and end_date and httpmethod = 'POST' and is_fvp = 0 --> is_fvp é uma flag que indica se o orgid é do teste de fvp ou não (descrito na introdução deste documento) and clientorgid <> serverorgid and additionalinfo_consentid is not null and statuscode like '2%' and orgid = clientorgid and is_in_denominador = 1 --> consentid's que estão no denominador da taxa and is_missing_security = 1 --> consentid's que não estão na base de security and endpoint = '/open-banking/resources/v3/resources' –- dados de clientes ) select ... from where 1=1 and -- numerador final (is_in_security = 1 --> consentimentos autorizados na base de security or is_in_apis_negocio = 1) --> consentimentos autorizados nas apis de negócio
-- As colunas que começam com "is_" são flags criadas ao longo do processo para validação. where 1=1 and ts_to_date_gmt between init_date and end_date and httpmethod = 'POST' and is_fvp = 0 --> is_fvp é uma flag que indica se o orgid é do teste de fvp ou não (descrito na introdução deste documento) and clientorgid <> serverorgid and additionalinfo_consentid is not null and statuscode like '2%' and orgid = clientorgid and is_in_denominador = 1 --> consentid's que estão no denominador da taxa and endpoint = '/open-banking/enrollments/v2/enrollments/{enrollmentId}/fido-registration' --vinculo
-- as colunas que começam com "is_" são flags criadas ao longo do processo para validação. with security as ------ busca security ( select ... from where 1=1 and ts_to_date_gmt between init_date and end_date and httpmethod = 'POST' and is_fvp = 0 --> is_fvp é uma flag que indica se o orgid é do teste de fvp ou não (descrito na introdução deste documento) and clientorgid <> serverorgid and additionalinfo_consentid is not null and statuscode like '2%' and organisationid = clientorgid and is_in_denominador = 1 --> consentid's que estão no denominador da taxa and endpoint = '/token' and additionalinfo_granttype = 'AUTHORIZATION_CODE' ), apis_negocio as ---- busca por uso de negócio ( select ... from where 1=1 and ts_to_date_gmt between init_date and end_date and httpmethod = 'POST' and is_fvp = 0 --> is_fvp é uma flag que indica se o orgid é do teste de fvp ou não (descrito na introdução deste documento) and clientorgid <> serverorgid and additionalinfo_consentid is not null and statuscode like '2%' and orgid = clientorgid and is_in_denominador = 1 --> consentid's que estão no denominador da taxa and is_missing_security = 1 --> consentid's que não estão na base de security and endpoint = '/open-banking/payments/v4/pix/payments' ) select ... from where 1=1 and -- numerador final (is_in_security = 1 --> consentimentos autorizados na base de security or is_in_apis_negocio = 1) --> consentimentos autorizados nas apis de negócio
-- as colunas que começam com "is_" são flags criadas ao longo do processo para validação. with security as ------ busca security ( select ... from where 1=1 and ts_to_date_gmt between init_date and end_date and is_fvp = 0 --> is_fvp é uma flag que indica se o orgid é do teste de fvp ou não (descrito na introdução deste documento) and clientorgid <> serverorgid and additionalinfo_consentid is not null and statuscode like '2%' and organisationid = clientorgid and httpmethod = 'POST' and is_in_denominador = 1 --> consentid's que estão no denominador da taxa and endpoint = '/token' and additionalinfo_granttype = 'AUTHORIZATION_CODE' ), apis_negocio_post as ---- busca por uso de negócio ( select ... from where 1=1 and ts_to_date_gmt between init_date and end_date and is_fvp = 0 --> is_fvp é uma flag que indica se o orgid é do teste de fvp ou não (descrito na introdução deste documento) and clientorgid <> serverorgid and statuscode like '2%' and additionalinfo_consentid is not null and orgid = clientorgid and is_in_denominador = 1 --> consentid's que estão no denominador da taxa and is_missing_security = 1 --> consentid's que não estão na base de security and httpmethod in ('POST') and endpoint like '%/pix%' and (additionalinfo_paymenttype = 'SWEEPING' or additionalinfo_paymenttype is null) ), apis_negocio_get_patch as ---- busca por uso de negócio ( select ... from where 1=1 and ts_to_date_gmt between init_date and end_date and is_fvp = 0 --> is_fvp é uma flag que indica se o orgid é do teste de fvp ou não (descrito na introdução deste documento) and clientorgid <> serverorgid and statuscode like '2%' and orgid = clientorgid and additionalinfo_originalrecurringpaymentid is null and is_in_denominador = 1 --> consentid's que estão no denominador da taxa and is_missing_security = 1 --> consentid's que não estão na base de security and httpmethod in ('GET', 'PATCH') and endpoint like '%recurring-consents%' and (additionalinfo_paymenttype = 'SWEEPING' or additionalinfo_paymenttype is null) and additionalinfo_status = 'AUTHORISED' ) select ... from where 1=1 and -- numerador final (is_in_security = 1 --> consentimentos autorizados na base de security or is_in_apis_negocio_post = 1 or is_in_apis_negocio_get_patch = 1) --> consentimentos autorizados nas apis de negócio
-- as colunas que começam com "is_" são flags criadas ao longo do processo para validação. with security as ------ busca security ( select ... from where 1=1 and ts_to_date_gmt between init_date and end_date and is_fvp = 0 --> is_fvp é uma flag que indica se o orgid é do teste de fvp ou não (descrito na introdução deste documento) and clientorgid <> serverorgid and additionalinfo_consentid is not null and statuscode like '2%' and organisationid = clientorgid and httpmethod = 'POST' and is_in_denominador = 1 --> consentid's que estão no denominador da taxa and endpoint = '/token' and additionalinfo_granttype = 'AUTHORIZATION_CODE' ), apis_negocio_post as ---- busca por uso de negócio ( select ... from where 1=1 and ts_to_date_gmt between init_date and end_date and is_fvp = 0 --> is_fvp é uma flag que indica se o orgid é do teste de fvp ou não (descrito na introdução deste documento) and clientorgid <> serverorgid and statuscode like '2%' and additionalinfo_consentid is not null and orgid = clientorgid and is_in_denominador = 1 --> consentid's que estão no denominador da taxa and is_missing_security = 1 --> consentid's que não estão na base de security and httpmethod in ('POST') and endpoint like '%/pix%' and additionalinfo_paymenttype = 'AUTOMATIC' ), apis_negocio_get_patch as ---- busca por uso de negócio ( select ... from where 1=1 and ts_to_date_gmt between init_date and end_date and is_fvp = 0 --> is_fvp é uma flag que indica se o orgid é do teste de fvp ou não (descrito na introdução deste documento) and clientorgid <> serverorgid and statuscode like '2%' and orgid = clientorgid and additionalinfo_originalrecurringpaymentid is null and is_in_denominador = 1 --> consentid's que estão no denominador da taxa and is_missing_security = 1 --> consentid's que não estão na base de security and httpmethod in ('GET', 'PATCH') and endpoint like '%recurring-consents%' and additionalinfo_paymenttype = 'AUTOMATIC' and additionalinfo_status = 'AUTHORISED' ) select ... from where 1=1 and -- numerador final (is_in_security = 1 --> consentimentos autorizados na base de security or is_in_apis_negocio_post = 1 or is_in_apis_negocio_get_patch = 1) --> consentimentos autorizados nas apis de negócio

O numerador da Taxa de Conversão também pode ser obtido por meio da análise do funil de conversão (detalhado na seção 9.5.) disponível no painel de produtos, utilizando a etapa de “Consentimentos Autorizados”.

5.3. Fonte Planilhas

As colunas utilizadas nas planilhas para o cálculo da taxa de conversão estão dispostas nas imagens abaixo, com o produto de acordo com a planilha.

Planilha: Fase 2 e 4b – Dados de Clientes Aba: Consentimento Transmissor
Planilha: Fase 3 – Pagamentos Aba: Funil API Pagam

5.4. Exemplo Taxa de Conversão unificada para pagamentos

Conforme mencionado anteriormente, o monitoramento contempla três produtos: Dados de Clientes, Vínculo e Pagamentos.

Nesta seção, apresentamos um exemplo de como é calculada a taxa de conversão do produto Pagamentos. Esse produto é composto pelas modalidades Pagamento com Redirecionamento, Pix Automático e Transferências Inteligentes.

Como cada modalidade possui um volume diferente de solicitações de consentimento válidas, a taxa de conversão do produto Pagamentos não é obtida pela média simples das taxas individuais. Em vez disso, é calculada por meio de uma média ponderada, em que o peso de cada modalidade corresponde à sua quantidade de solicitações de consentimento válidas (denominador da taxa).

No exemplo a seguir, considere uma instituição X, com as respectivas taxas de conversão e quantidades de solicitações de consentimento válidas para cada modalidade:

Produto

Taxa de Conversão

Solicitações Válidas (Peso)

Produto

Taxa de Conversão

Solicitações Válidas (Peso)

Pagamento com Redirecionamento

(Fonte: Planilhas)

59,7%

44.303

Pix Automático

(Fonte: bases da PCM)

47,3%

1.300

Transferências Inteligentes

(Fonte: bases da PCM)

61,8%

16.212

Total

—

61.815

Nesse cenário, a taxa final de conversão do produto Pagamentos é calculada por meio da seguinte média ponderada:

image-20260806-192040.png

6. Interpretação dos Resultados (Meta)

Tendo estabelecido a metodologia de apuração da taxa de conversão, torna-se necessário definir os parâmetros que determinam se o desempenho do participante está adequado aos padrões do ecossistema. Esse acompanhamento é estruturado a partir de três métricas de referência: a Meta (ou Top 3), a Taxa de Tolerância e a Taxa de Diagnóstico, detalhadas a seguir.

6.1. Cálculo das Metas (TOP 3)

Essa métrica define o benchmark de excelência do mercado e é calculado da seguinte forma:

  1. Calcula-se a taxa de conversão em uma janela de 3 meses, incluindo o mês de referência, para cada conglomerado;

  2. Dentre os 19 maiores conglomerados, identificam-se as instituições com as três maiores taxas de conversão;

  3. Calcula-se a taxa ponderada dessas três maiores taxas, definindo-se a meta Top 3;

  4. Esse valor serve de referência para a definição dos demais limiares

6.2. Taxa de Tolerância

A Taxa de Tolerância é o piso de conformidade. Instituições cuja taxa de conversão se mantiver acima dela são consideradas conformes. Ela é obtida tomando-se 80% da Taxa Top 3 e subtraindo-se 3 pontos percentuais, para acomodar pequenas variações operacionais.

TAXA DE TOLERÂNCIA = (80% × TAXA TOP 3) − 3 p.p

6.3 Taxa de Diagnóstico

A Taxa de Diagnóstico é o limiar inferior de severidade. Se a taxa de conversão de uma instituição cair abaixo dela, será necessária uma avaliação independente por empresa especializada para diagnosticar e corrigir os problemas subjacentes da jornada.

TAXA DE DIAGNÓSTICO= 60% × (80% × TAXA TOP 3) = 48% × TAXA TOP 3

6.4. Limiares Estabelecidos

Com base nas taxas calculadas acima, a instituição participante pode se enquadrar em um de três estados de conformidade apresentados abaixo.

Estado

Condição

Tratamento

Estado

Condição

Tratamento

Conforme

Taxa da instituição ≥ Taxa de Tolerância

Nenhuma ação regulatória é disparada

Desconforme

Taxa de Diagnóstico ≤ Taxa da instituição < Taxa de Tolerância

A instituição deve justificar porque se encontra nessa situação

Diagnóstico

Taxa da instituição < Taxa de Diagnóstico

A instituição deve adotar ações corretivas para retornar ao patamar de conformidade

7. Cálculo das Notas

A nota (0 a 10) traduz a taxa de conversão — numerador ÷ solicitações válidas — em escala de conformidade, ancorada em duas metas: Taxa de Diagnóstico (piso) e Taxa de Tolerância (nota 7).

  • Taxa da instituição < Diagnóstico → nota 0 (Falha Total)

  • Taxa Diagnóstico ≤ Taxa da instituição < Taxa Tolerância → nota 0 a 7: (Taxa − Tx. Diagnóstico) × 7 ÷ (Tx. Tolerância − Diagnóstico)

  • Tolerância ≤ Taxa da instituição < 100% → nota 7 a 10: 7 + (Taxa − Tx. Tolerância) × 3 ÷ (1 − Tx. Tolerância)

  • Taxa da instituição ≥ 100% → nota 10

  • Sem solicitações válidas → sem nota

A nota é truncada em 1 casa decimal (não arredondada) — por isso a média do sistema não cai exatamente sobre as linhas inteiras.

Faixas: Conforme (7–10)Desconforme (0–7) Diagnóstico(0)

Abaixo temos um gráfico que mostra esse comportamento.

image-20260804-202942.png

Na tabela abaixo, segue exemplos do cálculo das notas, considerando uma taxa diagnóstico de 33% e uma taxa de tolerância de 58%.

Taxa da Instituição

Cálculo da Nota (Diag 33% / Tol 58%)

Nota

Faixa

Taxa da Instituição

Cálculo da Nota (Diag 33% / Tol 58%)

Nota

Faixa

25%

abaixo da Diagnóstico

0

Diagnóstico

45%

(0,45 − 0,33) × 7 ÷ 0,25

3,3

Desconforme

57,5%

(0,575 − 0,33) × 7 ÷ 0,25

6,7

Desconforme

70%

7 + (0,70 − 0,58) × 3 ÷ 0,42

7,8

Conforme

100%

conversão de 100%

10

Conforme

8. Outras métricas do painel

8.1. Percentual de solicitações de consentimento válidas

Esta métrica mensura a proporção de requisições de consentimento consideradas válidas em relação ao volume total de solicitações recebidas. Indica a qualidade das chamadas iniciais no ecossistema antes da aplicação de filtros do funil.

% DE SOLICITAÇÕES VÁLIDAS = (QTD DE SOLICITAÇÕES VÁLIDAS ) / (TOTAL DE SOLICITAÇÕES DE CONSENTIMENTO)

O percentual de solicitações de consentimento válidas também pode ser obtido por meio da análise do funil de conversão (detalhado na seção 9.5.) disponível no painel de produtos, utilizando as etapas do funil na relação a seguir.

% PERCENTUAL DE SOLICITAÇÕES VÁLIDAS = (Consentimentos não autorizados visão negócio e /token + Consentimentos autorizados) / Total

8.2. Coeficiente de Impacto

Este índice quantifica a perda total de solicitações ao longo do funil de conversão. Corresponde ao volume de solicitações de consentimento que, embora tenham sido consideradas válidas na entrada, não atingiram o status final de autorização. O Coeficiente tem como objetivo mensurar o quanto a Taxa de Conversão da instituição analisada foi prejudicada por um conjunto de solicitações com um client específico. Dessa forma, na visão “Detalhamento dos clients” (seção 9.4) no painel de produtos, os clients são exibidos em ordem decrescente de acordo com o Coeficiente de Impacto.

COEFICIENTE DE IMPACTO = (QTD DE SOLICITAÇÕES VÁLIDAS) - (QTD DE CONSENTIMENTOS AUTORIZADOS)

9. Interpretação dos Dados no Painel

9.1. Controles

O painel é interativo. Seleções realizadas sobre linhas de tabelas interferem nos filtros aplicados nas visões posteriores. Para retornar a visão sem filtros basta selecionar “Redefinir para original”.

img1.png

Desta forma, têm-se em “Controles”:

image-20260818-132047.png

Ao clicar nos três pontos ao lado de um filtro, é possível Atualizar as opções de filtragem disponíveis de acordo com os dados mais recentes ou Redefinir o filtro, retornando às opções originalmente carregadas.