Short Dump Blog - Updated 7/2/2026 - 11 min read
SAP GTS 2025: Bank details and identification numbers in SPL screening
Why screening bank master data, account holders and identification numbers changes the evidence model for blocked partners.
Author: Rastislav Janak / s4hanahub team
Problem definition
A partner name can look clean while a bank detail, SWIFT/BIC or account holder name quietly changes the screening story.
The uncomfortable question
When a partner is blocked, can the reviewer distinguish a name match from a financial-data match before calling it a false positive?
Bank data brings a different kind of evidence into SPL screening. The risky signal may be attached to the payment route, not the partner name printed on the business card.
This topic deserves serious training because it changes how users read blocked-partner evidence: partner, bank, identification number and account holder each need a place in the explanation.
Here is the project version: SAP GTS 2025 expands SPL screening around bank-related data. That sounds simple, which is how SAP topics lure us into underestimating them.
Identification numbers such as SWIFT/BIC and bank numbers can be transferred and stored as business partner identification numbers, bank statuses can influence customer and supplier screening, and account holder names can be screened as additional names.
The SAP evidence trail is less romantic: This matters because financial identifiers can be compliance-relevant even when the partner name and address do not produce a direct match. A customer or supplier can be blocked because an associated bank is blocked, or because an account holder name creates a relevant match. In a clean demo this takes minutes; in production it asks for ownership, variants and a little courage.
This is where the support ticket usually starts: The operational impact is visible in Manage Blocked Partners and audit trail evidence. Users need to understand whether the match comes from the partner name, address, identification number, bank, or account holder. The screen is only the stage. The process is the plot.
Without that distinction, business teams may challenge the block as a “false name match” when the real signal is financial data.
The control angle is the part worth underlining: Implementation requires careful configuration. Partner functions must save transferred IDs and bank details, legal regulation settings must activate the relevant checks, and comparison procedures must include account-holder screening where required. A consultant should be able to explain this without opening a thirty-slide apology deck.
For training, the useful lesson is this: This is one of the most important training topics in the 2025 release because it changes how users read blocked-partner evidence. That is the difference between technical navigation and knowledge people can reuse.
The best training scenario should include a partner with no direct name hit but a blocked associated bank, and a second partner where the account holder creates the match.
The partner looked innocent. Then the bank detail entered the room and the audit trail cleared its throat.