Sinqia (Evertec) Attack — Technical Report

Executive Summary

This report details how an attacker exploited trust relationships and legitimate automations to issue PIX payment orders that were technically correct from a protocol perspective but had a fraudulent purpose. The incident exposed a critical blind spot in real-time settlement payment ecosystems, particularly where Payment Service Technology Providers (PSTIs) centralize sensitive assets for multiple clients. Any weakness in segregation or governance can amplify the impact.

In the case of Sinqia, early signs emerged during a period of low operational supervision: financial transactions via PIX were signed in batches with fractional values and sent to newly created recipients. Funds were quickly moved, reducing the chance for reactive blocking. It is important to note that this incident was limited exclusively to the provider’s transactional system and did not affect the Central Bank or other institutions.

The response required selective suspension of connectors, emergency rotation of secrets, revocation of vendor access, and coordination with the regulator for hold/recall procedures. The objective of this analysis is to map the chain of compromise, relate the techniques used to the PIX context, and translate these lessons into practical controls. The recommendations are guided by three pillars:

1. Identity and privilege — who can sign, from where, and under what safeguards. 
2. Secrets and trust — where keys/tokens reside, how they are scoped, rotated, and monitored. 
3. Business resilience — limits, holds, dual approval, and trusted lists that contain losses even when the order is valid.

Ultimately, operational goals should converge on a simple principle: the combined time for detection and blocking must always be shorter than the average cash-out window. Only then will the systemic risk posed by “one-to-many” providers shift from being a loss multiplier to a manageable element of the ecosystem.

Detailed Technical Analysis of the Sinqia (Evertec) Attack

The following sections outline the sequence of events, technical architecture, chain of compromise, and the controls that shaped detection, containment, and recovery.

1) Timeline 

The following timeline summarizes milestones and decisions that shaped the response. 

On August 29, 2025, signs of unauthorized activity were detected in the transactional environment, triggering the preventive suspension of part of the processing. In the following hours, PSTI and affected financial institution teams correlated indicators: out-of-schedule job execution, unusual certificate fingerprints, and transfers to new recipients.

Between August 30 and 31, blocks were coordinated, and communication to the regulator began. Vendor-associated credentials were revoked and replaced with new cryptographic material. From September 2 to 10, a massive rotation of keys and tokens took place, alongside a review of profiles with signing permissions and the hiring of external forensics, including preserved collection and trail analysis. Concurrently, affected clients resumed non-critical flows in a controlled manner under reinforced policies for limits, velocity, and quarantine for new recipients. 

In the following weeks, contractual and regulatory adjustments solidified measures: the requirement for strong client segregation, a live inventory of signers, periodic evidence of mTLS with pinning, and controlled provider shutdown drills. 

Notably, the critical window was in the first 24–48 hours, when the dispersion of values and conversion into crypto reduced the potential for recall. Thus, the readiness to activate kill switches and tier-based holds had to be tested and standardized. The central lesson from the chronology is clear: the speed of correlation and key governance is as critical as the speed of PIX itself; delays of hours mean settled orders and consolidated losses.

2) Operational Architecture 

The operational design connecting financial institutions to SPI/PIX combines authenticated channels, client certificates, queues/messaging, and integration automations. PSTIs, such as Sinqia, offer this ready-made layer, reducing cost and time to deployment, but introducing a concentration of sensitive assets: private keys, service tokens, technical accounts, and execution pipelines.

The secure reference architecture is based on three premises: 

1. Client segregation across all dimensions: cloud accounts, projects, secrets, certificates, transactional limits, and telemetry. 
2. Minimized and verifiable trust: mTLS with pinning, client-specific CN policies, signing in HSM/KMS, and automated rotation with a short window and a live inventory of who signs what, from where. 
3. Observability and governance: immutable trails, UEBA/ITDR correlation between human identity and workloads, and risk triggers integrated into SOAR capable of imposing holds and revoking credentials within minutes. 

In real environments, the topology includes bastions for managed jumps, CI/CD runners with ephemeral credentials, and API gateways with rate limits and canary tokens. The absence of any of these layers creates shortcuts for the adversary: static secrets in repositories, certificates reused out of scope, perennial service accounts, and broad permissions. 

Since SPI settlement is real-time gross settlement (RTGS, known in Brazil as LBTR), purely "at destination" controls are insufficient; it is at the source, at the time of signing, that the architecture must prevent undue emissions or, at least, make them visible and reversible in a timely manner.

3) Flow — Chain of Compromise

The chain of compromise in this case is characterized by abuse of legitimacy: instead of noisy malware or exploitation of novel vulnerabilities, the adversary operated with valid credentials and within routines that the business itself recognizes as normal. 

1. The flow begins with operational access by a third party, often enabled for support, integration, configuration, or routine playbook execution. 
2. This is followed by the silent discovery of signing routes and service accounts with permission to issue orders. 
3. The critical stage comes from secret handling: private keys, certificates, and tokens stored outside HSM/KMS or embedded in scripts and pipelines. 
4. In possession of this material, the attacker signs messages and sends batches with fractional values to recently created recipients, aiming for statistical invisibility. 
5. The next step is cash-out: credit to intermediary accounts, dispersal among institutions, and rapid conversion to crypto/OTC. 
6. In parallel, there are attempts to reduce the trail: selective log clearing, alterations to collection, and use of HTTPS channels indistinguishable from corporate traffic. 

Effective containment reverses the flow: upon identifying an unexpected signer or anomalous pattern, emission is frozen, secrets are rotated, tier-based holds are imposed, and blocks are coordinated with the regulator. 

The swimlane representation, attached to this report, highlights decision points and actionable telemetry to shorten the time between suspicion and blocking.

4) Flow — Detection, Containment, and Recovery

Effective detection in scenarios of abused legitimacy requires moving away from an exclusive reliance on IOCs and prioritizing behavior.

The starting point is business features: 

• Order velocity per operator/service
• Recipient affinity
• Atypical hours
• Runner origin
• Certificate fingerprints

When the combination exceeds dynamic thresholds, automated actions are triggered, such as: 

• Quarantine of new recipients
• Temporal holds based on value range
• Out-of-band dual approval requirements
• Blocking of the associated runner’s credential

Next, containment at the source: 

• Pause the affected PIX connector
• Rotate tokens and certificates
• Invalidate active sessions via PAM/SSO 

For the forensic trail: 

• Preserve immutable logs (WORM)
• Capture bastion trails
• Export API gateway events
• Correlate "who signed what, from where, on behalf of whom" 

Secure recovery involves:

• Rebuilding pipelines
• Restoring mTLS policies with pinning
• Running sanity tests with canary accounts and low-value transactions

At the same time, teams must communicate with clients and regulators about the partial scope, remediation steps, and any block/recall requests.

Palliative measures that postpone key rotation or maintain open exceptions tend to be re-exploited. Therefore, the authority to activate kill switches and approve risk windows must be clear, available 24x7, and auditable.

5) Flow — Recommended Controls (Identity, Transaction, Governance)

Flow 3 organizes controls into three domains. 

1. Identity & Access: apply PAM/ITDR to third parties (vendors, managed services) with physical MFA, JIT access, session recording, and command control for sensitive operations; isolate service accounts and adopt strong segregation of credentials by client/integration; secret vault with automatic rotation (post-use, incident-driven, and scheduled) — ideally with HSM or equivalent modules and minimum scope per function.
2. Transaction & Detection: trusted recipient list and quarantine for new ones; tier-based limits and holds/escrow for high value with out-of-band dual approval; risk engines with velocity, time/day deviation, recipient affinity, and channel telemetry (client fingerprints, SNI, certificate CN); real-time alerts for FIs and the regulator when risk thresholds are crossed. 
3. Governance: contracts with shared responsibility, periodic audits of PIX/SPI integrations, continuity tests (RTO/RPO), and emergency plans for controlled PSTI shutdown; periodic tabletop and red team exercises focused on the signing/settlement trail; inventory of keys and trails of who can sign per client/use case. 

These controls do not depend on changes to the SPI; they reside at the edge (PSTI/FI) where orders originate and are signed. The expected result is to reduce maximum impact per window (limits/holds), shorten time-to-detection (telemetry/behavior), and make the abuse of third-party credentials difficult (PAM/MFA/HSM). 

6) Technical Hypotheses (Probable TTPs)

The plausible TTPs align with ATT&CK for attacks involving abuse of legitimacy in supply chains. Initial access via T1078 (Valid Accounts) in combination with bribery/insider abuse or previously exposed credentials; alternatively, exploitation of exposed services or messaging brokers (where applicable) for initial pivot. 

Discovery and movement aim at mapping integrations and the signing trail, enumerating keystores/HSMs, automated jobs, and service accounts. Impact materializes with the injection of signed messages (Execution via legitimate automation), timing outside business hours, and fractionalization to mask spikes. Evasion stems from the correct protocol: since the message is valid and signed, the SPI settles it; therefore, defense must be at the source, reinforcing secret segregation and transactional limits. 

Auxiliary hypotheses include inadequate credential scope (same key for multiple clients/integrations), automation tokens with broad privileges, and insufficient telemetry for rapid triage. In response, hunters must prioritize signing trails (which CNs sign, from which jobs/hosts), profile deviations (new recipients, velocity, time), and vendor session artifacts (salt, RMM consoles, VPN). 

Consider T1195 (Supply Chain) as the tactical framework: the PSTI is the aggregation point where the attacker finds scale. Public reports on the C&M attack — an analogous case in 2025 — describe this same pattern of legitimacy abuse, evidencing how secrets/signatures at the PSTI become high-value assets for adversaries.

7) Observed Impacts (as of Oct 06, 2025)

The impacts unfold in four dimensions:

1. Financial: Direct losses derived from debiting settlement accounts and recovery costs; in some cases, coordinated recalls and blocks mitigate the damage, but initial dispersion reduces the success rate. 
2. Operational: Preventive pauses of connectors and pipeline reconstruction affect payment SLAs and require extraordinary windows for secure testing. 
3. Regulatory: Hardening measures, including temporary caps, licensing/segregation requirements, and closer supervision of the third-party chain, raise the minimum compliance standard. 
4. Reputational: The perception of fragility in "one-to-many" providers pressures boards and executive teams to prioritize investments in identity, secrets, and transactional controls. There is also systemic risk: when multiple FIs share the same PSTI, the probability of correlated events increases. 

A positive side effect is collective maturity: after such incidents, playbooks are standardized, integrations begin to require evidence of client segregation, and signer inventories become routine. The metric that best reflects progress is the maximum impact per window; when limitations, holds, and dual approval consistently reduce this magnitude, the ecosystem absorbs shocks with less aggregate loss, even in the face of subsequent attempts.

8) Prioritized Recommendations

Prioritize initiatives that immediately reduce the blast radius and time to containment. 

• In identity and privilege, establish PAM with physical MFA, JIT elevation, and task-based approval; eliminate permanent vendor credentials; record all privileged sessions and prohibit lateral jumps outside bastions. 
• In secrets and certificates, move keys to HSM/KMS, apply mTLS with pinning, define distinct CN/policies per client, and perform automatic rotation; adopt a secret vault with dynamic injection and short leases for workloads. 
• In detection and response, implement UEBA/ITDR with velocity/affinity limits, automatic quarantine of new recipients, and canary tokens in APIs; integrate with SOAR to revoke tokens/roles and activate kill-switches. 
• In business controls, impose holds based on value ranges and out-of-band dual approval for high-risk transactions; maintain managed trusted lists and verification processes for adding new beneficiaries. 
• In governance, institute a live inventory of signers, periodic audits of PIX integrations, PSTI shutdown drills, and revocation SLAs in minutes. 

Measure progress by MTTD/MTTR, effective block rate, and sustained reduction in maximum impact per window.

9) Due Diligence (FIs/Regulator)

To reduce the risk asymmetry between clients and providers, due diligence must shift from generic checklists to verifiable technical evidence. 

• Contractually require client segregation in the identity, secrets, and network layers; demonstrate, by sample, that signing keys reside in HSM/KMS and that mTLS channels use pinning and specific CN policies. 
• Demand a live inventory of signers and audited break-glass with deadlines and responsible parties. 
• Evaluate readiness for emergency rotation of certificates and tokens, including coordinated communication plans for FIs and the regulator. 
• Test, via tabletop or red team exercises, the signing → settlement → block/recall trail, with minute-based targets for revocation and hold activation. 
• Verify the existence of immutable logs (WORM) and integration with SIEM/SOAR; also, evaluate rate limits and canary tokens on API gateways. 

For the regulator, it is recommended to standardize minimum evidence artifacts, define maximum reaction times, encourage client-specific kill-switches, and promote inter-institutional exercises. 

Due diligence is not a one-time act: it must be continuous, with quarterly evidence cycles and control re-composition when scope changes occur.

10) Techniques Used by Threat Actors (MITRE ATT&CK)

The plausible TTPs align with ATT&CK for attacks involving abuse of legitimacy in supply chains. 

• Initial access via T1078 (Valid Accounts) in combination with bribery/insider abuse or previously exposed credentials; alternatively, exploitation of exposed services or messaging brokers (where applicable) for initial pivot. 
• Discovery and movement aim at mapping integrations and the signing trail, enumerating keystores/HSMs, automated jobs, and service accounts. 
• Impact materializes with the injection of signed messages (Execution via legitimate automation), timing outside business hours, and fractionalization to mask spikes. 
• Evasion stems from the correct protocol: since the message is valid and signed, the SPI settles it; therefore, defense must be at the source, reinforcing secret segregation and transactional limits. 

Auxiliary hypotheses include: 

• Inadequate credential scope (same key for multiple clients/integrations)
• Automation tokens with broad privileges
• Insufficient telemetry for rapid triage

In response, hunters must prioritize signing trails (which CNs sign, from which jobs/hosts), profile deviations (new recipients, velocity, time), and vendor session artifacts (salt, RMM consoles, VPN). Consider T1195 (Supply Chain Compromise) as the tactical framework: the PSTI is the aggregation point where the attacker finds scale. Public reports on the C&M attack—an analogous case in 2025—describe this same pattern of legitimacy abuse, evidencing how secrets/signatures at the PSTI become high-value assets for adversaries.

11) Public Landscape and Developments (media, values, and authorities) — Sep/2025

Public coverage of the incident helps contextualize the technical timeline and the perception of systemic risk across the payment ecosystem.

On Aug 30, 2025, major news outlets reported that the company operating PIX integrations had been the target of an attack involving an estimated ~BRL 420 million diversion. This was an initial figure, reflecting partial snapshots and the inherent difficulty of consolidating data within short time windows. In practice, batch fragmentation and dispersion across newly created recipients favored later revisions, as enhanced monitoring and hold/recall requests moved through multiple institutions.

By the second half of September, behind-the-scenes accounts raised the estimate to ~BRL 710 million across two clients. This reinforced the one-to-many nature of risk when a PSTI integrates several participants. Importantly, available technical communications have remained focused exclusively on the PIX environment, with the impact limited to a small number of institutions and no evidence of spillover into other core banking systems. This is consistent with the RTGS (known in Brazil as LBTR) design and the role of business controls at the point of origination.

Coordinated law-enforcement efforts began following the incident, with investigations involving injunctions, artifact collection, and financial inquiries. This movement reinforced two governance messages:

• Remaining readily available to, and cooperating with, authorities through dedicated channels accelerates blocking orders, telemetry sharing, and evidence preservation.
• The convergence between technical trails (WORM logs, bastion sessions, mTLS with certificate pinning, and signer inventories) and legal documentation (chain of custody) is critical to support effective blocking and recall requests.

At this stage, it is also advisable to publicly confirm, where appropriate, that no suspicion involves any client outside the already communicated scope. Doing so mitigates reputational noise and keeps attention on concrete containment actions.

From a sector learning perspective, reports in the press and official statements help shape both narratives and regulatory expectations. To preserve trust, organizations should publish objective updates such as:

• “The affected environment was PIX within a single transit account and subsequent dispersal.”
• “Telemetry identified financial transactions through official integration with timing and correlation anomalies.”
• “We continue enhanced monitoring and controls and maintain ongoing cooperation.”

By anchoring communications in verifiable data and demonstrated response capability, an organization conveys maturity and reduces uncertainty — even when client or fund estimates remain under review.

12) Mitigation — How Solutions Reduce Risk and Impact

Mitigating attacks involving the abuse of legitimacy requires complementary layers that break the three conditions for the adversary's success: signing, sending, and cashing out quickly. 

• In Identity & Access, PAM with physical MFA, JIT access, task-based approval, session recording, and command control removes the "permanent" nature of vendor accounts and creates useful forensic trails. 
• In Secrets & Signatures, Personal Vault for individuals and Secrets/Token Management for workloads enforce scope per client, automatic post-use rotation, short leases, and dynamic credential injection (no hardcoding). Digital Certificates under HSM/KMS, mTLS with pinning, and client-specific CN/policies prevent a signing material from being reused out of context. 
• In Detection & Response, UEBA/ITDR profiles operators and services to detect deviations (times, velocity, recipient affinity), while rate/velocity limits and canary signals on APIs help contain bursts. 
• Cloud Solutions reinforce least privilege with workload identity federation, policy-as-code (OPA), immutable logging, and segmentation by account/project, reducing the blast radius. 
• Finally, transactional controls are independent of the SPI and are decisive: holds/escrow and out-of-band dual approval for high value; trusted list and quarantine for new recipients; client-specific kill-switches and canary accounts for sanity checks. These mechanisms reduce the maximum impact per window, even under valid credentials. 

Operationally, institute regular tabletop/red-team exercises focused on the signing→settlement trail, revocation SLAs in minutes, and a live inventory of who/how signs. Continuously measure time-to-detection and time-to-block; optimize so that the sum of these times is less than the average cash-out window observed in the ecosystem.

1. PAM — Privileged Access Management

PAM is the backbone for taming vendor privileges in PSTIs. By centralizing credentials and enforcing physical MFA (FIDO2) and JIT access, the exposure of fixed passwords is eliminated, and the validity time of credentials is reduced—a direct antidote to T1078 (Valid Accounts). With session recording and command control, all privileged activity becomes observable and reconstructible, deterring T1070 (Indicator Removal) and shortening forensics. 

Integrations with change management allow high-risk actions (e.g., certificate changes, integration job alterations) to occur only with task-based approval and within defined windows. For automation, PAM must issue ephemeral credentials (short lease) linked to the context (who, which integration, which client), preventing transversal reuse across environments/clients. 

In hybrid scenarios, combine PAM + bastions with session recording and jump policies (no inadvertent lateral RDP/SSH), mitigating T1021 (Remote Services). 

Practical KPIs: 

• % of JIT vs. permanent accesses
• Post-incident revocation time
• Physical MFA coverage 

The goal is to transform vendor privilege into an ephemeral, auditable event under fine control, drastically reducing the potential for abuse of legitimacy.

2. Personal Vault (Personal Secret Store)

Executives and operators often store tokens/cookies/passwords in browsers or notes. Personal Vault dematerializes this habit by providing encrypted storage, secure recovery, and expiration policies. Integrated with SSO, the surface area for T1555 (Password Stores) and T1552.001 (Credentials in Files) is reduced, in addition to offering alerts when secrets are copied/exported. 

In spear-phishing or social engineering incidents, the vault enforces MFA and revalidation for credential exfiltration, delaying the adversary and generating actionable telemetry. The vault must support controlled sharing (e.g., a contingency password) with impeccable auditing and instant revocation. 

For personal API tokens (support, operation):

• Use short leases and minimum scope.
• Integrate the vault with PAM so that elevated credentials never remain at rest on the endpoint. 
• Browser hardening policies (turning off native password manager, isolating profiles) complement the protection. 

Result: lower probability of exploitable valid accounts and increased time-to-impact for the intruder, as each sensitive access passes through additional barriers and leaves forensic traces.

3. User Monitoring — UEBA/ITDR

UEBA/ITDR builds behavioral profiles of people and services and detects subtle deviations—essential when the attacker uses valid credentials. 

In PSTI/PIX, model features such as time/day, velocity (orders/minute), recipient affinity, bastion hops, TLS fingerprints (JA3/SNI), and runner origin. Adaptive rules capture low-and-slow: multiple average values for new recipients over hours. 

Connect UEBA to SOAR for automatic/semi-automatic blocking: placing a recipient in quarantine, triggering hold/escrow, or revoking the runner's token. Integrate PAM, CI/CD, API Gateway, and HSM/KMS sources to correlate "who signed what" with "who executed." 

KPIs: 

• Behavioral MTTD
• % of alerts with action (hold/quarantine)
• False positives per client

The focus is on recognizing patterns of abuse of legitimacy that fall below the radar of traditional IOCs and shortening time-to-block until it is less than the typical cash-out window.

4. DevOps Secrets & Token Management

The attacker's target is the moment of signing. A Secrets/Token Management program prevents static secrets in code/pipelines. 

• Use dynamic injectors from the vault/KMS for jobs, with routes by identity (person vs. workload) and scope by client/integration. 
• Automatic post-use rotation, short leases, audience limits (audience/claims in tokens), and repository DLP reduce T1552/T1555. 
• In automation, prefer workload identity federation (no long keys) and signing in HSM; runners receive ephemeral credentials tied to policy-as-code. 
• Pre-commit hooks and CI guards block merging with secrets in the clear. 

The vault telemetry (issuance/use/revocation) feeds UEBA/ITDR and SOAR to revoke tokens upon detecting anomalies. 

Result: even if a runner is compromised, the blast radius remains scoped and temporally limited.

5. Digital Certificates (HSM/KMS, mTLS with Pinning, Rotation)

Certificates and keys materialize the authority to issue orders. Store them in HSM/KMS, with mTLS and pinning to prevent T1553 (Subvert Trust Controls). 

• Use distinct CN/policies per client and a live inventory of certificates, with programmed rotation and audited break-glass. 
• Each signature must be linked to identity, host, pipeline, and client, enabling technical repudiation when something deviates. 
• Monitor certificate issuance/replacement and new fingerprints; trigger holds if an unexpected signer appears. 

This prevents the attacker from "signing on behalf of everyone," and any deviation triggers coordinated blocks.

6. Cloud Solutions (Identity Federation, Policy-as-Code, Immutable Logging)

In cloud environments:

• Use identity federation for workloads (no static keys), managed secrets, KMS, and minimum roles per project/account, reducing T1078 and T1552. 
• Policy-as-code ensures coherence (OPA/ABAC), and immutable logging (Storage WORM, object lock) prevents T1070. 
• Network segmentation and private endpoints shield brokers and HSMs. 
• Integrate CloudTrail/Activity Logs with UEBA and SOAR to automatically revoke roles and trigger holds when a signer/runner appears outside the pattern.

7. Transactional Controls (Holds/Escrow, Dual Approval, Trusted List, Quarantine, Velocity, Kill-Switches)

These controls break the impact even with valid credentials. 

• Holds/escrow add deliberate delay and out-of-band dual approval for high tiers; a trusted list maintains usual recipients, while quarantine secures new ones until validation. 
• Velocity/affinity rules trigger temporal blocking and notification to the FI/PSTI. 
• Client-specific kill-switches and canary accounts allow for flow interruption and channel testing in production with controlled risk. 

This reduces the maximum impact per window and extends the reaction window for investigation and recovery.

Conclusion

The Sinqia incident illustrates how adversaries can weaponize legitimate credentials and automations to execute fraud that bypasses traditional defenses. Because transactions were valid at the protocol level, containment depended on rapid correlation, key governance, and coordinated action with regulators.

The lessons are clear: controls must be enforced at the point of origination, with strict segregation of identities and secrets, behavioral monitoring to detect anomalies, and business safeguards such as holds, dual approvals, and trusted lists. Providers and financial institutions share responsibility for ensuring that the combined time to detect and block remains shorter than the attacker’s cash-out window.

By institutionalizing these practices—through technology, governance, and continuous testing—the ecosystem can transform systemic risk from a loss multiplier into a manageable factor, strengthening resilience against future abuse of legitimacy. Going forward, maturity will be measured not by the absence of incidents, but by the speed and effectiveness of detection, containment, and recovery.

How Segura® Helps

Segura® provides the tools to put these controls into practice. Our platform combines Privileged Access Management, Secrets Management, Certificate Lifecycle Management, and Identity Threat Detection into a unified solution. With fast deployment, strong segregation, and continuous monitoring, we help financial institutions and providers reduce exposure to legitimacy abuse and enforce resilience at the point of signing.

[Explore Segura’s Identity Security Platform Now ›]

Public References (verified Oct 06, 2025)

• SEC — Evertec Form 8-K (Aug 29, 2025): SEC Filing
• Apura Cyber Report (Aug 2025): LinkedIn Post
• Evertec Investor Relations — Form 8-K (Sep 2, 2025): IR Filing
• BleepingComputer (Sep 2, 2025): Hackers Breach Fintech Firm in Attempted $130M Bank Heist
• Insurance Journal (Sep 2, 2025): Hackers Breach Brazil Fintech in $130M Heist Attempt
• Bloomberg (Aug 30, 2025): Cyberattack on Evertec’s Sinqia Hits HSBC, Others in Brazil
• BankInfoSecurity (Sep 3, 2025): Hackers Exploit Brazil’s PIX Payment System for $130M Theft
• Global Government Fintech (Sep 10, 2025): Brazil’s Central Bank Boosts Security After PIX Cyberhacks
• Reuters (Sep 5, 2025): Brazil’s Central Bank Enhances Security After Cyberattack