This guide provides detailed instructions on how to use a digital signature for a scheduled Pix-out transfer transaction.

A Prestadores de Serviços de Tecnologia da Informação (PSTI)—Information and Technology Service Provider in English—is a technology service provider that connects to the banking/financial infrastructure (specifically the Rede do Sistema Financeiro Nacional – RSFN) on participants' behalf.

Issuers need to find and work with a PSTI and a provider to create and store a public/private key pair used in encryption.

A private key is a secret piece of data used in cryptography to decrypt messages or digitally sign information. It is part of a public key pair, with a corresponding public key that can be shared openly. The private key is kept confidential and is used to perform actions like decrypting data sent to you or proving your identity by digitally signing transactions

A digital signature is a secure electronic signature that uses cryptography to verify signer identity and a digital document's integrity. It creates a unique "hash" of the document, which is then encrypted with the sender's private key. This process provides authentication (proof of identity), data integrity (ensuring the document hasn't been altered), and non-repudiation (preventing the signer from denying they signed it).

The digital signature in Pix-out requests is being introduced to ensure the integrity and authenticity of messages sent to the PSTI during transfers via Pismo's REST API. This control is essential to meet the Brazilian Central Bank's regulatory requirements, which mandate that all messages sent to the SPI (Instant Payment System) be PSP (Payment Service Provider) signed.

Pismo works with your PSTI to implement the digital signature.

How an Issuer works with a PSTI for Pix

Here are typical steps and considerations:

Step 1 - Select or contract with a PSTI

The issuer identifies a PSTI which provides connectivity to the RSFN and the Pix scheme.
The contract must clearly define roles, responsibilities, data flows, security, segregation of duties, and compliance responsibilities.
Because the recent regulatory changes focus on PSTIs, the issuer must ensure the PSTI meets heightened governance and security standards.

Step 2 - Ensure regulatory authorisation and compliance

The issuer must obtain the appropriate authorisation from the BCB if required (payment institution status, and so on.).
The issuer must ensure that the PSTI is properly credentialled (or will be) and meets BCB eligibility criteria (capital minimum, governance, risk management).
The contract between issuer and PSTI must be aligned with the regulatory framework for Pix participation (for example, who is “responsible participant,” how outsourcing is handled).

Step 3 - Technical integration and operational setup

The issuer must integrate its systems (accounting, settlement, reconciliation, fraud monitoring) with the PSTI infrastructure.
The PSTI typically provides the connectivity, messaging, settlement path, often certificate management, key management, and so on..
The issuer must define in the contract how private keys, transaction signing, fraud monitoring, and integrity checks are handled (especially given recent rules about what PSTIs can/cannot do).

For example: PSTIs are now not permitted to store private Pix keys in some circumstances, and participants must validate transaction integrity prior to signing.

The issuer needs to coordinate with the PSTI on operational hours, message volumes, latency, settlement cycles, reconciliation, and error handling.

Step 4 - Governance, risk and security obligations

The issuer remains primarily responsible for regulatory compliance, even if outsourcing to a PSTI. So governance must include PSTI oversight.
Because the BCB has imposed specific security requirements on PSTIs and participants, the issuer must ensure the PSTI meets standards: e.g., certificates separate for environment/production, monitoring real-time fraud, separation of duties, no key-sharing, and so on.
The issuer must monitor the PSTI’s performance, audits, risk events (cyber-attacks, availability issues). The BCB has pointed out that many recent failures were due to PSTIs.

Step 5 - Transaction limits, and special rules if using a PSTI

A key recent regulatory change: If the issuer (or institution) is connecting to the RSFN via a PSTI, and does not satisfy all enhanced security/governance criteria, then the transaction limit for Pix or TED is set at BRL 15,000 per transaction.
If the issuer and PSTI demonstrate full compliance (such than independent auditor report, separate certificates, no sharing of private Pix keys, transaction integrity checks) then the limit may be waived (temporarily up to 90 days) while full compliance is achieved.
The issuer needs to decide whether to go via indirect participation (via PSTI) with limits or aim to become a direct participant (avoiding some of the limitations, but incurring more obligations). Example: One company moved from being indirect via a PSTI to direct Pix participant.

Step 6 - Ongoing monitoring and compliance

The issuer must continually monitor the PSTI for compliance with the contract and with regulatory requirements (security, governance, risk).
It should have an audit/reporting schedule to ensure changes in PSTI's infrastructure (e.g., certificate renewal, key changes) don’t impact the issuer’s obligations.
The contract should include termination rights, continuity plans, fallback arrangements if the PSTI fails or is de-credentialed.

How Pismo works with a PSTI

You create the digital signature with an asymmetric private key using either the Elliptic Curve or RSA algorithm. Encryption is done over a buffer with PSTI stipulated data extracted from the message payload. This ensures message integrity and authenticity and its non-repudiation (assurance that a party involved in a transaction cannot later deny their involvement). This integrity is guaranteed from end to end between the bank and PTSI for subsequent transmission to Bacen (Brazilian Central Bank).

PSTI performs the signature validation using the public key correlated with the private key. PSTI must generate and store the public key. Pismo acts as a pass-through entity in this process.

Transaction flow

For each transaction:

Step 1 - Call the scheduled transfer endpoint

Call the. scheduled transfer endpoint. This generates the "Collect a scheduled Pix-out signature notification" event.

Step 2 - Determine event data to sign

You have two options for signing event data:

Sign the data_to_be_signed field
Build a string buffer to be signed from event data as follows:

"[`psp_transaction_created_at`],[`end_to_end_id`],[MASK(currency, ".00", amount)],[MASK("left_zeros_padding", "00000000", payer.bank)],[MASK("left_zeros_padding", IF(cpf, "00000000000", "00000000000000"), payer.document_number)],[MASK("left_zeros_padding", "00000000", payee.bank)],[MASK("left_zeros_padding", IF(cpf,"00000000000", "00000000000000"), payee.document_number)]"

Where: MASK() defines the mask over the input data, for example:

Mask over the “document_number” - a CNPJ, with 14 characters at minimum, and with left “0”s to fill the size.

Example: CNPJ 4358798000107 (14 positions) must be: “04358798000107”

Note: Cadastro Nacional da Pessoa Jurídica (CNPJ) is a 14-digit federal tax identification number issued to all legal entities and businesses operating in Brazil.

Buffer example:
"2025-07-28T19:07:03.023Z,E00038166201907261559y6j6mt9l0pi,150.85,04358798,11111111111,04358799,04358798000107"

Step 3 - Calculate the digital signature:

The signature must be compatible with the asymmetric algorithm (DSA), which performs a hash of the data (buffer) and subsequently encrypts the data with the private key.

Choose one of Elliptic Curve or RSA with a Secure Hashing Algorithm (SHA):

ECDSA_P256_SHA256
ECDSA_P384_SHA384
Ed25519
RSA_PKCS1_SHA256

Step 4 - Base64 encode

Base64 encode the digital signature:

For example: signature = Base64.Encode( signatureBinary )

Step 5 - Pass signature in Pix-out digital signature collector endpoint

Pass the signature in the signature_info object field in the Pix-out digital signature collector endpoint call.

Scheduled Pix-out transfer encryption