Atlassian uses cookies to improve your browsing experience, perform analytics and research, and conduct advertising. Accept all cookies to indicate that you agree to our use of cookies on your device.
Atlassian uses cookies to improve your browsing experience, perform analytics and research, and conduct advertising. Accept all cookies to indicate that you agree to our use of cookies on your device. Atlassian cookies and tracking notice, (opens new window)
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.
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:
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:
Calcula-se a taxa de conversão em uma janela de 3 meses, incluindo o mês de referência, para cada conglomerado;
Dentre os 19 maiores conglomerados, identificam-se as instituições com as três maiores taxas de conversão;
Calcula-se a taxa ponderada dessas três maiores taxas, definindo-se a meta Top 3;
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.
Abaixo temos um gráfico que mostra esse comportamento.
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”.
Desta forma, têm-se em “Controles”:
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.