Category
UI/UX Design, Banking, FinTech
UI/UX Design, Banking, FinTech
Responsibility
UI/UX, Design System, Wireframing, Prototyping, Concept Testing
UI/UX, Design System, Wireframing, Prototyping, Concept Testing
New Real Time Gross Settlement Transactions
New Real Time Gross Settlement Transactions
New Real Time Gross Settlement Transactions
RTGS (Real Time Gross Settlement) is one of the financial transaction modules within NDS (New Delivery System) at BRI. Unlike scheduled transactions, RTGS uses funds that have already been validated by the Payment Hub and are sent in real time to Bank Indonesia without a scheduler. Once processed by BI, the funds are immediately forwarded to the beneficiary account.
Because the transaction is instant and typically involves high value transfers, it requires a higher level of data accuracy and authorization control compared to standard transactions.
RTGS in NDS supports 3 transaction methods, such as Tunai, Rekening, Kartu, and 5 transaction types based on different use cases, Transaksi Antar Bank, Antar Nasabah, Antar Nasabah–Surat Berharga Pasar Modal, Antar Bank Penarikan Kas, Antar Bank Pengembalian.
RTGS (Real Time Gross Settlement) is one of the financial transaction modules within NDS (New Delivery System) at BRI. Unlike scheduled transactions, RTGS uses funds that have already been validated by the Payment Hub and are sent in real time to Bank Indonesia without a scheduler. Once processed by BI, the funds are immediately forwarded to the beneficiary account.
Because the transaction is instant and typically involves high value transfers, it requires a higher level of data accuracy and authorization control compared to standard transactions.
RTGS in NDS supports 3 transaction methods, such as Tunai, Rekening, Kartu, and 5 transaction types based on different use cases, Transaksi Antar Bank, Antar Nasabah, Antar Nasabah–Surat Berharga Pasar Modal, Antar Bank Penarikan Kas, Antar Bank Pengembalian.
Design challenges
Design challenges
Design challenges
Real time transaction without scheduler
Real time transaction without scheduler
RTGS transactions are processed in real time without a scheduler. Therefore, the design needed to ensure that data validation was completed before approval, rather than relying on post-transaction cancellation.
RTGS transactions are processed in real time without a scheduler. Therefore, the design needed to ensure that data validation was completed before approval, rather than relying on post-transaction cancellation.
Non nasabah data may not already exist in the bank’s system
Non nasabah data may not already exist in the bank’s system, requiring tellers to manually enter WIC information from their ID card. This manual process increases the risk of errors, such as incorrect NIKs or mismatched names, potentially affecting the KYC process.
Identity verification requires a reliable source
The system needs to provide confidence that the entered identity information is valid, ideally through an official source such as Dukcapil. However, the design also needs to accommodate service unavailability through a controlled manual verification fallback.
High transactions require layered authorization
Data validation alone is not sufficient for sensitive transactions. The flow also requires authorization from an authorized supervisor before the transaction can be submitted, reducing the risk of errors reaching the execution stage.
Non nasabah data may not already exist in the bank’s system
Non nasabah data may not already exist in the bank’s system, requiring tellers to manually enter WIC information from their ID card. This manual process increases the risk of errors, such as incorrect NIKs or mismatched names, potentially affecting the KYC process.
Identity verification requires a reliable source
The system needs to provide confidence that the entered identity information is valid, ideally through an official source such as Dukcapil. However, the design also needs to accommodate service unavailability through a controlled manual verification fallback.
High transactions require layered authorization
Data validation alone is not sufficient for sensitive transactions. The flow also requires authorization from an authorized supervisor before the transaction can be submitted, reducing the risk of errors reaching the execution stage.
Goals
Goals
Goals
• Ensure WIC identity data is accurately validated before the transaction can proceed to approval.
• Provide field level validation feedback so tellers can immediately identify and correct inaccurate information.
• Create a flow manual verification fallback when Dukcapil verification is unavailable.
• Separate data entry and validation from review and authorization to ensure that approvals are based on finalized and verified information.
• Ensure WIC identity data is accurately validated before the transaction can proceed to approval.
• Provide field level validation feedback so tellers can immediately identify and correct inaccurate information.
• Create a flow manual verification fallback when Dukcapil verification is unavailable.
• Separate data entry and validation from review and authorization to ensure that approvals are based on finalized and verified information.
Approach
Approach
Approach
Validate early
Validate early
RTGS transactions are processed directly without a scheduler, the Dukcapil validation process is placed as a gate before the data can proceed to the Preview & Approval stage.
RTGS transactions are processed directly without a scheduler, the Dukcapil validation process is placed as a gate before the data can proceed to the Preview & Approval stage.
Provide field level validation
Provide field level validation
Each identity field receives an individual validation status after the Dukcapil verification process. Rather than displaying a generic “Data sesuai 0/ data tidak sesuai 0%” message, field-level feedback helps tellers immediately identify which information needs to be reviewed or corrected.
Each identity field receives an individual validation status after the Dukcapil verification process. Rather than displaying a generic “Data sesuai 0/ data tidak sesuai 0%” message, field-level feedback helps tellers immediately identify which information needs to be reviewed or corrected.
Uses different color to communicate status
Uses different color to communicate status
Yellow indicates information that is currently being entered or edited by the teller, and grey indicates information that is autofield.
Yellow indicates information that is currently being entered or edited by the teller, and grey indicates information that is autofield.
Duckapil as primary flow
Duckapil as primary flow
Validasi Manual option remains disabled until Validasi Dukcapil process has been attempted or has failed.
This ensures that official verification remains the primary path, while manual validation functions strictly as a controlled fallback rather than an alternative shortcut.
Validasi Manual option remains disabled until Validasi Dukcapil process has been attempted or has failed.
This ensures that official verification remains the primary path, while manual validation functions strictly as a controlled fallback rather than an alternative shortcut.
Make preview & approval as review point
Make preview & approval as review point
Preview & Approval screen designed as a read-only summary. The screen presents all details in a structured format without unnecessary editing elements.
Meanwhile the Approval System is integrated directly into the final review screen rather than being treated as a separate administrative process.
Preview & Approval screen designed as a read-only summary. The screen presents all details in a structured format without unnecessary editing elements.
Meanwhile the Approval System is integrated directly into the final review screen rather than being treated as a separate administrative process.
Extend verification before approval
Extend verification before approval
The authorization flow is not one size fits-all. Transactions below the teller’s authorization limit can be submitted directly, while transactions exceeding the limit are automatically routed to SPV approval. Then after SPV approval, the transaction continues through Remote Approval, SVS (Sign Verification System), and password authentication before final execution.
The authorization flow is not one size fits-all. Transactions below the teller’s authorization limit can be submitted directly, while transactions exceeding the limit are automatically routed to SPV approval. Then after SPV approval, the transaction continues through Remote Approval, SVS (Sign Verification System), and password authentication before final execution.
Project impact
Project impact
Project impact
• Established a structured identity validation flow for nasabah and non nasabah transactions, reducing the risk of manual input errors in a real-time transaction environment.
• Separated data validation from review and authorization.
• Designed a tiered authorization model based on transaction limits.
• Improved visibility into validation status and helping tellers identify and correct inaccurate identity information.
• Established a structured identity validation flow for nasabah and non nasabah transactions, reducing the risk of manual input errors in a real-time transaction environment.
• Separated data validation from review and authorization.
• Designed a tiered authorization model based on transaction limits.
• Improved visibility into validation status and helping tellers identify and correct inaccurate identity information.
Category
UI/UX Design, Banking, FinTech
Responsibility
UI/UX, Design System, Wireframing, Prototyping, Concept Testing