SCT Inst: instant euro payments

An instant payment settles in seconds, not days. An SCT Inst payment is credited to the payee account within ten seconds, twenty four hours a day, seven days a week, including weekends and holidays. Once the payee bank has credited the money, the payment is final and cannot be undone by the payer bank alone. Speed is the whole point of the scheme, and every part of the flow has to be built for a ten second budget. The Instant Payments Regulation requires execution within 10 seconds, and the SCT Inst rulebook maximum execution time is 10 seconds; the design target is ten, and a bank that regularly takes longer has a problem. Source: Regulation (EU) 2024/886; EPC SCT Inst Rulebook. The payer starts with a pain.001, as in SCT. The instruction reaches the payer bank as a pain.001, exactly like a standard credit transfer. The difference is what happens next. Fraud screening, sanctions screening, the funds check, and the verification of payee must all complete in real time, in milliseconds, because there is no batch window to hide behind. A bank that screens in minutes cannot offer instant payments. The analyst must confirm the latency of each check with the team that owns it, and must design the payment to be rejected cleanly if a check cannot complete in time, rather than left pending. Follow one payment end to end, with the clock running. A customer in Spain sends 4,200 euro to a friend in Germany at 23:40 on a Sunday. At second zero the payer bank receives the pain.001 and starts the checks. By second one, the fraud screen and the sanctions screen have passed, the balance check has confirmed the funds, and the verification of payee has returned a match. At second two the payer bank sends a pacs.008 through the instant clearing system, RT1 operated by EBA Clearing, or settles in central bank money through TIPS, the TARGET Instant Payment Settlement service. At second four the payee bank receives the pacs.008, validates the account and credits the friend 4,200 euro. At second five the payee bank returns a pacs.002 with status ACCP. At second six the payer bank shows the customer a confirmation. The money has moved across a border, on a Sunday night, in six seconds. The ten second budget breaks down into parts, and each part has an owner. Fraud screening and sanctions screening must complete in milliseconds. The funds check must complete in milliseconds. Verification of payee must complete in under a second. The pacs.008 transit through the clearing system must complete in one to two seconds. The payee bank's account check and credit must complete in one to two seconds. The pacs.002 return must complete in one to two seconds. If any part is slow, the whole payment is slow, and the analyst must have a latency budget for each part, with monitoring and alerting when any part exceeds it. A payment that takes nine seconds because the fraud screen took seven is a fraud screen problem, not a payments problem. Verification of payee checks the name against the IBAN. Before the money moves, the payer bank checks whether the name the payer typed matches the name on the beneficiary account. The answer is a match, a close match, or no match. A no match warns the payer that the IBAN may belong to someone else, which is the classic pattern in authorised push payment fraud. Under the Instant Payments Regulation this check is mandatory, and the payer must see the result and confirm before the payment is sent. The analyst must design the user experience for each result: a match proceeds silently, a close match shows the correct name and asks the payer to confirm, and a no match shows a clear warning and asks the payer to check the details by a trusted route. Settlement is where TIPS and RT1 differ, and the analyst must know which one their flow uses. TIPS, the TARGET Instant Payment Settlement service, settles the payment in central bank money in real time, so the interbank settlement is instant in the same way the customer experience is instant. RT1, the instant clearing system operated by EBA Clearing, clears the payment instantly and settles the net positions between banks through T2 at defined times. In both cases the customer sees instant credit, but the liquidity and risk are different: with TIPS the sending bank needs central bank liquidity at that moment, while with RT1 the sending bank needs to fund its net position at the settlement cycle. The analyst should state which settlement model the product uses, because it drives the treasury funding rules and the reconciliation design. A timeout is a rejection, not a mystery. If the payee bank does not answer within the deadline, the clearing system rejects the payment and sends a pacs.002 with a timeout reason. The payer bank does not debit the payer, or it reverses any reservation it made, and the payer is told clearly that the payment failed. Nothing is left pending. A payment stuck in an unknown state is worse than one that failed cleanly, because the payer does not know whether to try again, and trying again risks a duplicate. The product must show a timeout as a clear failure with the reason, and must offer the customer the choice to retry or to send a standard SCT instead. Rejects use the same reason codes as SCT. The payee bank rejects with a pacs.002 and a familiar reason code, such as AC01 for an incorrect account number, AC04 for a closed account, AG01 for a forbidden transaction, AM04 for insufficient funds, or AM05 for a duplicate. If the payee bank does not support SCT Inst, the payer bank must fall back to a standard SCT payment and say the money will take up to one business day. The fallback must be explicit: the customer chose instant, the receiving bank cannot receive instant, and the payment will now take a day. A silent fallback to SCT is a defect, because the customer paid for speed and got slowness without being told. Recalls work the same way, but speed changes the risk. A payment sent in error can be recalled with a camt.056 cancellation request, and the payee bank answers with a camt.029. The payee must consent before the money comes back, and by the time a recall is raised the money has usually already been spent, because ten seconds leaves no time to stop it. Prevention matters more than cure, which is why verification of payee and real time fraud screening sit before the payment. The analyst should tell the business plainly: for instant payments, the fraud controls before the payment are the only controls that matter, because there is no control after it. The regulation made instant the default. The Instant Payments Regulation, Regulation (EU) 2024/886, requires banks in the euro area to receive instant payments from 9 January 2025 and to send them from 9 October 2025. An instant payment must cost the customer no more than a standard credit transfer, and verification of payee is mandatory. Sanctions screening moved from a check on every payment to a daily check against the sanctions lists, because a per payment check cannot fit inside ten seconds. The analyst must confirm the sanctions approach with compliance: the daily list check replaces the per payment check only where the regulation allows it, and the payment must still be screened against the lists that apply. There is no scheme maximum amount for SCT Inst since the 2025 rulebook removed the 100,000 euro cap effective 5 October 2025; each PSP sets its own limits for its customers. Source: EPC 2025 SCT Inst Rulebook. The limit can vary by channel and by customer segment, so the product must show the applicable limit before the customer types the amount. A payment above the limit must be offered as a standard SCT with the one business day timing stated, or rejected with a clear message. The analyst checklist for instant payments has five checks: the ten second budget must hold across fraud, sanctions and liquidity; both ends must be ready, or the payment falls back to SCT; real time status screens must show accepted, rejected or timed out; reconciliation must match every pacs.008 against its pacs.002 within seconds; and the verification of payee result must be recorded with the payment, because it is the evidence the bank needs if the customer later claims fraud. A worked example with the failure case shows the design. The customer sends 4,200 euro at 23:40 on a Sunday. The verification of payee returns a close match, because the friend's name is spelled with an accent the customer omitted. The screen shows the correct name and asks the customer to confirm. The customer confirms, the payment goes through in six seconds, and the friend is credited. Now suppose the verification of payee returns no match. The screen warns the customer that the name does not match the account, and the customer realises they typed the wrong IBAN. They cancel, correct the IBAN, and the payment goes through. Without verification of payee, the 4,200 euro would have gone to a stranger, and the recall would have depended on that stranger's consent. That is the value of the check, and it is why the regulation made it mandatory.