O contrato de BaaS distribui tarefas entre instituição regulada, provedor de tecnologia e empresa P2P. Essa divisão parece organizada enquanto o cliente abre conta, envia Pix e recebe ativos sem ocorrência. O problema aparece quando uma das partes assume a obrigação de decidir e outra conserva a informação necessária. A instituição deve responder ao evento bancário, o P2P conhece a ordem e a wallet, e o provedor mantém os registros da interface. Se o dado circula por pedido manual e depende de pessoas específicas, a responsabilidade foi escrita, mas não foi colocada em funcionamento.
A expressão “cliente do parceiro” costuma esconder esse defeito porque a instituição enxerga uma pessoa que usa infraestrutura regulada e precisa ser conhecida dentro dos deveres aplicáveis, o P2P enxerga o comprador que aceitou cotação e indicou endereço, e o provedor enxerga um registro criado por API. Os três olhares pertencem à mesma pessoa, porém utilizam identificadores e níveis de informação diferentes. Quando o Pix contestado não leva diretamente ao cadastro, à ordem, à decisão de liberação e ao txid, cada empresa consegue provar uma parte e nenhuma consegue explicar o caso inteiro dentro do prazo.
O contrato precisa descer ao nível da decisão, porque “monitoramento pelo parceiro” não informa quem cria o alerta, quem enxerga a titularidade do Pix, quem interrompe a entrega e quem autoriza a liberação. “Atendimento pelo P2P” também não define quem responde a uma reclamação sobre bloqueio da conta ou indisponibilidade do Pix. Para cada evento, a cadeia deve indicar dado de entrada, pessoa ou área responsável, prazo, autoridade, registro de saída e caminho de escalada. A instituição regulada conserva os deveres atribuídos pela norma, ainda que contrate terceiros para executar parte do trabalho.
A tela apresentada ao cliente merece a mesma atenção porque, se uma única marca conduz cadastro, conta, negociação e guarda, o usuário forma uma expectativa de responsabilidade integrada. Termos espalhados entre links e empresas pouco identificadas não neutralizam necessariamente aquilo que a própria jornada comunica. Comprovantes, avisos de bloqueio e canais de atendimento precisam deixar clara a entidade responsável por cada serviço. A diferença entre aparência e contrato amplia disputas sobre quem deveria ter evitado a perda, preservado a informação ou respondido ao pedido.
Proteção de dados exige finalidade definida, acesso restrito, segurança e uso adequado, mas não sustenta um arranjo que mantém o decisor sem informação. O desenho correto entrega o dado mínimo para quem toma a decisão e registra cada consulta. Se o P2P analisa fraude sem conhecer o titular do Pix, ou se a instituição responde ao MED sem acessar cotação, endereço e txid, o arranjo economizou integração às custas da capacidade de defesa. Canal de contingência precisa existir antes da falha da API e ter prioridade compatível com os prazos reais.
O encerramento revela se a cadeia foi bem construída porque saldos, ordens abertas, chaves, registros, solicitações anteriores e deveres de atendimento continuam existindo depois do fim comercial. O contrato deve garantir exportação utilizável e acesso às provas durante o período necessário, sem depender da boa vontade de um ex-parceiro. Em BaaS, a distribuição de responsabilidade ganha valor quando acompanha permissões, dados e continuidade, enquanto a separação desses elementos deixa cada empresa com obrigações que enxerga tarde demais.