Bradesco’s Cross-Border RTP Pilot: What Payment Operations Must Prove Before Scale

Bank of America reported on September 29 that Bradesco completed the first pilot transaction using BofA’s Cross-Border Real-Time Payments solution. The announcement was made at 9:00 AM Eastern, or 6:30 PM IST. The important word is pilot: this was a first controlled transaction, not evidence that a broad, always-on cross-border service is already available. For payment operators, the event is best read as a readiness case about how a message, a funding decision, a local-rail delivery and a customer-visible outcome must connect.

The transaction used Bradesco’s existing Swift connectivity and was delivered in Hong Kong dollars to a local beneficiary through Hong Kong’s Faster Payment System. That establishes a specific path rather than a generic claim about instant international payments. The source describes the use case as high-volume and low-value. It also says future initiation through CashPro is planned. Planned CashPro initiation is not live CashPro availability, and neither the announcement nor the research record establishes a production rollout across customers.

The banks are also piloting a separate U.S. route for consumer and small-business international payments. That route should not be combined with the Hong Kong path when operators assess readiness. A corridor has its own currency, local beneficiary rules, rail participation, funding model, screening logic, operating hours, exception handling and support responsibilities. Treating one completed pilot as proof for another corridor would erase the exact boundary that makes a payment-control review useful.

The first control is a written corridor definition. An operator should specify the origin institution, Swift message types and fields, permitted customer and payment categories, destination country, local currency, beneficiary route and Faster Payment System handoff. The definition should also state what is outside scope, including the separate U.S. pilot and future CashPro initiation until those capabilities are evidenced. A signed boundary prevents an implementation team from quietly converting a named pilot into a broader product promise.

Next comes Swift-to-local-rail mapping. Every instruction needs a deterministic translation from the incoming message to the local beneficiary, amount, currency, account or proxy details, and delivery instruction. The mapping should preserve a traceable identifier across the Swift message, internal processing record and Hong Kong FPS outcome. Operators should be able to show which fields were accepted, transformed, rejected or sent for review. A local instant-payment status should never be treated as a substitute for the original cross-border instruction record.

Funding and foreign exchange need their own evidence trail. Delivering Hong Kong dollars means the operator must know where the local funds come from, when liquidity is reserved, which party owns the currency conversion and how the applied amount is recorded. The reviewed sources do not disclose the FX method, fees or funding arrangement, so no particular model can be attributed to this pilot. Before scale, teams should document prefunding or liquidity dependencies, approval points, value dates, cut-off assumptions and what happens when the required currency is unavailable.

Beneficiary verification is another stop-or-proceed decision, not a cosmetic data check. The workflow should compare the intended beneficiary information with the fields required by the destination rail and record the result before local delivery. Operators should define how name, account or proxy mismatches, missing fields and duplicate instructions are handled. The pilot announcement does not disclose beneficiary-bank details or the verification method. That gap makes a documented control design and review queue more important, not less important, before additional payment types are admitted.

Sanctions, fraud and limits must operate before the irreversible local-rail handoff. A cross-border instruction can pass a message-format check and still require screening, risk scoring, velocity review or a manual decision. The operator should identify which sanctions screening event is authoritative, how fraud alerts stop release, which customer and corridor limits apply, and who can override a hold. The source does not provide a failure rate, limit set or screening result for the first transaction. Those unknowns should remain unknown rather than being filled with assumed performance.

Status propagation determines whether real-time delivery is also real-time information. A customer-facing system needs to distinguish received, validated, funded, screened, submitted, accepted, rejected, returned and completed states, with an owner and timestamp for each transition. A local Faster Payment System acceptance should not automatically be presented as final beneficiary availability if a later confirmation is required. Operators should test duplicate messages, delayed acknowledgements and contradictory statuses so that support teams can explain what happened without asking customers to repeat the entire payment.

Exception queues turn edge cases into owned work. A queue should separate mapping failures, funding or FX holds, beneficiary mismatches, sanctions or fraud reviews, local-rail rejects, returns and uncertain status events. Each category needs a priority, evidence requirement, escalation route and closure reason. The first pilot does not disclose how many exceptions occurred or how quickly any issue was resolved. A controlled rollout therefore needs queue-level measurement before it can claim that a corridor is operationally dependable.

Reconciliation should connect the instruction to money movement and customer communication. At minimum, operators need a repeatable comparison between the original Swift record, the internal transaction identifier, the funding or FX ledger, the local-rail result and any return or adjustment. Differences should create an exception rather than disappear into a daily total. The reviewed material does not disclose transaction value, production volume or reconciliation performance. Those omissions mean the next evidence should include breaks, aging, manual adjustments and unresolved items, not just successful delivery counts.

Support ownership must be explicit across the bank, the payment solution and the local rail. A customer or corporate treasury team needs to know who handles an instruction that is accepted by one system but missing from another, who can provide a status update, and who owns a returned or delayed payment. The operator should publish an internal service map with contact roles, escalation windows and evidence access. The sources do not disclose service levels, so operators should not infer a response promise from the word real-time.

Service-level evidence should cover the whole journey rather than a single network hop. Teams can define measures for intake, validation, screening, funding, submission, local-rail response, final confirmation, exception ageing and customer contact. They should record denominators and corridor scope so a small pilot is not compared misleadingly with a larger service. Because the announcement provides no elapsed time, failure rate, fee or independent performance data, the first transaction supports a controlled test—not a claim about speed, certainty or economics.

Resilience and rollback are required before controlled production. Operators should test a Swift-connectivity interruption, a local-rail outage, unavailable liquidity, screening-service failure, duplicate delivery risk and delayed status messages. The runbook should say when to pause new instructions, how to prevent retries from creating duplicates, how queued work is recovered and which team authorises restart. Rollback does not necessarily mean reversing a completed payment; it can mean stopping new submissions, preserving evidence and routing unresolved items to a safe manual process.

A sensible production gate would require evidence that the corridor boundary is enforced, mappings are tested, beneficiary checks and screening decisions are reviewable, funding and FX records reconcile, status states are customer-safe, exceptions have owners, and support can retrieve a complete case history. It should also require resilience exercises, recovery evidence and a documented rollback decision. None of these controls is presented as an outcome already achieved by Bradesco or BofA; they are the proof points payment operators should require before treating the pilot as ready for broader use.

Expansion should be earned in stages. The Hong Kong-dollar route can remain the reference corridor while operators review controlled production data, then consider additional customer segments, higher volumes or the separate U.S. route only after its own testing. Future CashPro initiation should receive a separate readiness gate because a new initiation surface changes authentication, entitlements, support and audit requirements. The practical lesson from this first pilot is narrow but useful: real-time cross-border payments scale when every handoff, hold, status, exception and recovery action has evidence and an accountable owner.

The practical lesson is narrow but useful: real-time cross-border payments scale when every handoff, hold, status, exception and recovery action has evidence and an accountable owner.

Published September 30, 2026 · Source event September 29, 2026