If you are sending an instant bank transfer in Paraguay, treat the final confirmation screen as the key safety checkpoint. SPI is the instant-transfer component of SIPAP, the payment system administered by the Central Bank of Paraguay. It operates continuously, and after the BCP’s March 2026 update the current SPI maximum is ₲10 million per operation. That figure is current as of 6 September 2026. It does not mean every bank app will show the same screens, charge the same fees, or allow the same customer-level controls.
The practical rule is simple: before sending, confirm the recipient through the bank’s interface, check whether the amount is within both the SPI rail limit and your bank’s own controls, and keep proof of the transaction. If money goes to the wrong person, a return request can be useful, but it is not an automatic reversal. The recipient must accept the request.
BCP currently describes SPI transfers between natural persons as free of charge. For a valid SPI operation, the current FAQ also gives the beneficiary institution a maximum of five seconds to credit the beneficiary's account. Those are payment-system rules; app display and additional customer security controls remain institution-specific.
What SPI is inside SIPAP
SIPAP is Paraguay’s national payment system administered by the BCP. SPI is the instant-transfer component within that system. For a customer, SPI is usually experienced through a bank or financial institution’s mobile app, web banking screen or payment flow, not through a standalone BCP app.
That distinction matters. The rail is the BCP-administered infrastructure that supports instant transfers. The screen, button labels, confirmation layout, security prompts, fees and customer-specific controls belong to each participating institution. A bank may make SPI feel like a simple transfer option, a QR-style payment flow, an alias lookup or a payment request, but the customer should still verify what the app is actually asking them to approve.
The current limit and what it does not promise
The current SPI maximum set by the BCP is ₲10 million per operation, following the March 2026 increase from ₲5 million. It is a per-operation rail limit, not a blanket promise that every customer can always send that amount in every circumstance.
| Point to check | What it means | What not to assume |
|---|---|---|
| SPI per-operation maximum | The BCP-set ceiling for one SPI transfer is ₲10 million. | Do not treat it as a daily, monthly or account-specific allowance. |
| Bank interface | Your bank decides how SPI appears in its app or web banking. | Do not expect identical labels or screens at every bank. |
| Customer controls | Your bank may apply security steps or customer-specific limits. | Do not assume the rail limit overrides bank-level controls. |
| Fees | Any fee presentation is bank-specific. | Do not assume all banks charge or display fees the same way. |
Before sending a high-value instant transfer, check the current BCP payment-system information and your own bank’s transfer screen. If either place shows a lower limit, an extra step or a warning, treat that as operative for your transaction.
Aliases and payment requests
The current SPI framework supports aliases, payment requests and return or request-return functions. These tools can reduce typing errors, but they do not remove the sender’s responsibility to confirm the recipient before authorizing a transfer.
An alias is useful because it can let a sender find or confirm a recipient without manually entering a full account number. A payment request can be useful when the person or business expecting money initiates a request that the payer reviews and approves. A return-request function can be useful after an error, because it gives a structured way to ask the recipient to send the money back.
The important caveat is interface design. One bank may show an alias confirmation screen with a prominent name field. Another may place the confirmation inside the last step of the transfer. A payment request might appear as a notification, a pending request, or a transfer approval screen. The same function can therefore feel different depending on the bank.
Before-send checklist
- Confirm that the operation is really an SPI instant transfer, not another transfer type inside the same bank app.
- Check that the amount is within the current SPI per-operation maximum and within any bank-specific control shown to you.
- Use an alias or payment request when available, but still verify the displayed recipient information.
- Compare the recipient name, alias, account reference or request details with an independent instruction from the person or business you intend to pay.
- Slow down at the final confirmation screen. Amount, recipient and concept are easier to correct before approval than after the transfer is sent.
- Save or screenshot the confirmation receipt in the normal way your bank provides it.
For businesses, a payment request can be safer than sending customers loose account details by message, because the customer reviews a structured request inside the banking environment. The customer should still check that the request matches the purchase, service or invoice they intended to pay.
If you sent money to the wrong recipient
A mistaken SPI payment should be handled quickly, but not with the expectation of an automatic chargeback. BCP describes SPI transfers as irrevocable. The request-return function nevertheless lets the sender request a return within ten days from the original payment; the recipient has within that same ten-day period measured from the original payment to respond. The return depends on the recipient's acceptance. After the window closes, money can still be sent back as a new transfer, but not through this SPI return-request option.
If the issue is suspected fraud rather than a typing mistake, BCP points to special financial-institution procedures: make a police report and ask the institution to seek return of the funds.
Use the following decision tree:
- Is the error caught before confirmation? Stop the transaction and correct the recipient, amount or payment request details.
- Was the transfer already sent? Save the receipt, amount, date, recipient information shown by the bank, transaction reference and any message or concept field.
- Does the bank app offer a return request? Use that function if available and keep the confirmation that the request was made.
- Does the app not show the function clearly? Contact your bank through its normal support channel and ask how to initiate a mistaken-payment return request under SPI.
- Did the recipient accept? Keep the return confirmation and reconcile the account movement.
- Did the recipient not accept or not respond? Keep the evidence trail and continue through your bank’s indicated process, understanding that the SPI function itself is not an automatic reversal.
Worked example
Suppose Ana wants to pay ₲3,200,000 to a supplier. The supplier sends a payment request through the bank. Ana opens the request and checks three things: the amount, the recipient identity displayed in the app and the reason for payment. The amount is under the current SPI per-operation maximum, but Ana still checks whether her own bank shows any customer-level restriction before approving.
If Ana instead typed an alias manually and selected the wrong recipient, the safer point to catch the mistake would be the confirmation screen. If she notices after sending, her next step is to preserve the receipt and use the bank’s return-request function or support channel. She can ask for the money to be returned, but the return depends on recipient acceptance.
What to recheck before relying on the system
SPI is designed for instant, continuous operation, but payment-system rules and bank interfaces can change. Recheck the BCP’s official SIPAP and SPI information for the current rail rules, and recheck your own bank’s app or support information for its interface, fees, customer controls and security steps. The safest habit is to treat each instant transfer as final unless and until a return is actually accepted and credited back.