pacs.028 payment status request: chasing a cross border payment when the settlement leg ran on chain

A pacs.028 payment status request is the message one institution sends when it needs to know what happened to a payment it has already instructed. The payment went out. No status came back, or the status that did come back is stale. The request asks the next party in the chain to say where the payment stands. It is a small message with a narrow job: the difference between an operations team that chases by telephone and one that chases by machine. When the cross border settlement leg runs on a public blockchain, the request changes shape, because the sender can already see part of the answer.

What is a pacs.028 payment status request?

pacs.028 is the ISO 20022 financial institution to financial institution payment status request. Its catalogue name is FIToFIPaymentStatusRequest. It sits in the same payments clearing and settlement family as pacs.008, pacs.009 and pacs.002.

The roles are easy to keep straight. A pacs.008 or a pacs.009 instructs a payment. A pacs.002 reports its status. A pacs.028 asks for that status when it has not arrived or is no longer current.

The request carries no money and changes nothing. It is a question, and the expected answer is a pacs.002. Swift includes the message in its CBPR+ usage guidelines for cross border traffic, where it takes over work that used to travel as a free format enquiry.

A free format enquiry has to be read by a person. A structured payment status request can be matched, answered and closed by software, because every field in it is defined.

When should you send a payment status request rather than wait?

The honest answer is that most institutions send too many, too early, and too often to the wrong party.

Four situations justify a request. The first is silence past your own service level, where the expected status report never came and the window you publish has closed. The second is a stale status, where you hold an acceptance from technical validation and nothing since. The third is a customer enquiry you cannot answer from your own records. The fourth is an investigation, where a cancellation or a compliance question needs the current position before anything else can move.

Polling is not one of those situations. Sending a request every few minutes turns a chase message into noise, and the party you are chasing will start treating all of them as noise.

Write the thresholds down. Name the wait before a first request, the interval before a second, and the point at which the case leaves the automated flow and goes to a person. Those three numbers belong in your operating procedure, not in the judgement of whoever is on shift.

What must a pacs.028 carry to be answerable?

A request is answerable when the receiver can find exactly one payment from it. Anything less puts a person in the loop, which is the cost the message exists to remove.

Carry the UETR first. The Swift CBPR+ guidelines require that unique end to end transaction reference on cross border payment instructions, and it is the one identifier that survives the whole chain. A request that carries it is a database lookup. A request that omits it is an investigation.

Carry the original message identification and the original instruction identification next, so the receiver can match on its own references if the first search fails. Carry the original end to end identification too, because that is the reference the sending customer knows.

Then carry the original amount, the currency and the interbank settlement date. These do not identify a payment on their own. They confirm that the payment the receiver found is the payment you meant.

Name the parties, the original instructing agent and the instructed agent. And give the request its own identification, because the answer has to point back at it.

How does a status request work when the settlement leg ran on a public blockchain?

On a correspondent chain, the sender is blind between hops. The status report is the only visibility there is. That blindness is why the chase message exists.

A stablecoin settlement leg removes part of it. The transfer is a transaction on a public ledger. The sender can see that it was broadcast, that it was included in a block, and how many blocks have since been built on top of it. None of that requires asking anyone.

On a public settlement leg the question changes. The sender no longer asks whether the value moved, because the ledger already answers that. The sender asks what the receiver has done with it, and only the receiver can answer that.

So the useful request on an on chain leg is narrower and better informed. State what you already know: the chain, the token, the transaction hash and the confirmation count you have observed. Ask about the part the ledger cannot show, which is the payout leg in the beneficiary market, the screening outcome, and any hold.

This removes a whole category of request. A sender who can see that a transfer has not yet reached the confirmation depth named in the policy has no reason to chase. The answer would only be that the receiver is still waiting.

The answer should be just as specific. A status of settlement completed on a leg the sender can verify is credible. A status that contradicts the ledger is a break, and it belongs in an exception queue.

How should an institution handle an incoming payment status request?

The receiving side is where most of the value is won or lost. A disciplined flow answers the majority of requests without a person reading them.

• Validate the request against the schema and your usage guideline, and store the message whole for the audit trail.
• Check the request identification against requests already answered, and treat an exact repeat as a duplicate rather than as new work.
• Find the payment on the UETR first and the original instruction identification second, and never on the amount alone.
• Confirm the match against the original amount, currency and settlement date before you answer anything.
• Establish the current position from your own records, including any compliance hold, and from the settlement ledger where the leg ran on chain.
• Answer with a pacs.002 that quotes the UETR, the original references and the request identification, and carries a defined status reason code.
• Say plainly when a payment is held for review, within what your policy and your legal obligations allow you to disclose.
• Close the case and record the elapsed time, so the service level can be measured rather than assumed.

Two of those steps deserve emphasis. Matching on amount alone will eventually pair the wrong payments, because two payments of the same value in the same hour are ordinary. And a reason code beats free text, because a code can be routed and counted while prose can only be read.

What goes wrong with payment status requests, and how do you avoid it?

Four failures cover most of it.

The first is the polling loop. An automated chase with no backoff floods the counterparty and buries the requests that matter. Set an interval, set a maximum, and escalate to a person instead of sending a tenth request.

The second is the missing reference. A request without a UETR or an original instruction identification cannot be matched automatically, so it lands in a queue and waits for someone to read it. The message meant to save time now costs it.

The third is answering with nothing. A status report that says only that the payment is pending, with no reason code and no date, ends nothing. The sender will ask again. Give the status, the reason, and when the position will change.

The fourth is treating a status request as a cancellation. It is not. A pacs.028 asks a question. Stopping a payment in flight is a camt.056 cancellation request, and returning value that has already settled is a pacs.004 return. Mixing the three leaves a team believing a payment was stopped when it was only asked about.

Measure the flow. Count requests sent per thousand payments, the share answered without a person, and the time to answer. A rising count usually signals weak status reporting upstream rather than the chase message itself.

The Financial Stability Board's October 2021 targets for the G20 cross border payments roadmap aim for 75 percent of cross border wholesale payments to be credited within one hour of initiation by the end of 2027, according to the FSB. A chase process measured in days does not fit inside an hour.

Where StableNet fits

StableNet, built by SpendTheBits, is a cross border B2B payment and settlement platform for banks, credit unions, licensed money service businesses, exchange houses and remittance fintechs. Settlement runs in regulated stablecoins such as USDC and USDT on public blockchains and completes in minutes with on chain auditability, so much of what a status request used to ask is visible to both parties before anyone sends one. The platform is ISO 20022 native, with pacs.008 customer credit transfers, pacs.009 interbank legs, pacs.002 status reports and pacs.004 returns inside head.001 envelopes, tracked end to end by UETR, so one reference joins the instruction, the chase and the answer. Compliance is built in, with KYB and KYC onboarding, KYT, sanctions and PEP screening, FATF Travel Rule data in IVMS101 form, a compliance workbench and a tamper evident audit trail. SpendTheBits is a Bank of Canada registered payment service provider and a named finalist in the Swift Hackathon 2026 Technical Challenge.