Building a stronger layer of financial trust.

What it is: Examines transaction details and available context to identify indicators of fraud, unusual activity or elevated risk. It gives the responsible institution a structured risk assessment.

How it could work: It can evaluate transaction details alongside permissioned identity, recipient, device, location and behavioural signals. It returns an assessment and reasons; it does not authorize or execute payments.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Current prototype. This label describes the current roadmap position, not a production service guarantee.

What it is: Converts relevant risk indicators into a consistent score or risk level. This helps institutions compare cases and apply their own review policies.

How it could work: It can evaluate configured indicators, apply documented weights or rules, and return a score with contributing factors. Scores require validation and cannot guarantee that a transaction is safe or fraudulent.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Current prototype. This label describes the current roadmap position, not a production service guarantee.

What it is: Provides advisory recommendations such as further checks or human review. It supports institutional decision-making but is not the payment decision itself.

How it could work: It can combine risk assessments, policy thresholds and explanation codes. The receiving institution retains control of authorization, execution and any decision to stop a transaction.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Current prototype. This label describes the current roadmap position, not a production service guarantee.

What it is: Explains why a transaction received a particular risk assessment, including contributing indicators, policy matches and important limitations.

How it could work: It can translate detected signals and applied rules into structured reason codes and plain-language explanations. It should distinguish observed evidence from assumptions and missing information.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: Creates a structured representation of relevant transaction attributes so related or repeated events can be compared without relying only on a transaction reference.

How it could work: It can derive a fingerprint from selected, normalized attributes using secure methods. The design must minimize personal data and account for legitimate transactions with similar attributes.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: Helps prevent the same request from being processed repeatedly within TrustNG when a client retries after a timeout or uncertain response.

How it could work: A request can carry an idempotency key stored with its identity and result. A matching retry can return the recorded result instead of repeating the internal operation. This does not guarantee external payment execution occurs only once.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Current prototype. This label describes the current roadmap position, not a production service guarantee.

What it is: Helps detect requests copied and resent outside their intended context, reducing the risk of an old or unauthorized request being treated as new.

How it could work: It can validate request signatures, timestamps, nonces and request identifiers alongside idempotency controls. Requirements depend on the integration protocol.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: Maintains records of transaction-related risk checks and events so authorized users can review assessments, investigate changes and understand events over time.

How it could work: It can store assessment results, timestamps, references, policy versions and status updates. Access controls, retention rules, data minimization and auditability are essential.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: Examines individual indicators and combinations of indicators that may affect transaction risk, including unusual patterns, recipient information and transaction velocity.

How it could work: It can validate available signals, assess relevance and combine them under documented rules or models. Source reliability, consent and missing data must be considered.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: Provides visibility into transaction lifecycle information supplied by an authorized bank or payment provider. TrustNG observes reported states; it is not the payment executor.

How it could work: An integration can receive provider status updates and map them to consistent lifecycle states. Provider confirmation remains the source of truth; a TrustNG status record is not proof that funds moved.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: Allows institutions to define and manage risk conditions reflecting their products, customers, operating environment and risk appetite.

How it could work: Authorized administrators can configure thresholds, conditions and policy versions. Changes should be access-controlled, tested, recorded and approved under institutional governance.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: Monitors incoming transaction-related events and risk signals as they arrive, helping institutions identify cases that may need prompt attention.

How it could work: It can evaluate events against configured rules and available intelligence, then produce assessments or alerts. Performance depends on integration quality, event delivery and data freshness.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: Allows institutions to test proposed risk rules and thresholds against historical, synthetic or otherwise approved test data before operational use.

How it could work: It can replay test cases against a selected policy version and compare outcomes, false positives and missed detections. Simulations must remain separate from live transaction processing.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: Organizes risk alerts so authorized teams can identify important cases, reduce duplicate notifications and track which alerts have been reviewed.

How it could work: Alerts can be assigned severity, linked to assessments, grouped and routed to designated teams. Acknowledgement and resolution records should be auditable.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: Routes higher-risk or unresolved cases to appropriate human reviewers or operational teams according to institutional procedures.

How it could work: Escalation can use configured thresholds, case ownership, response targets and review stages. Human oversight and institutional decision authority remain in place.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: Captures suitable outcomes from authorized reviews and partner systems to help assess whether risk rules and models are performing as intended.

How it could work: It can record reviewer outcomes and confirmed events with their source and confidence, then use approved data for evaluation. Feedback must be quality-checked and must not automatically change production policies.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: Allows a recipient to create a TrustNG email identity record that can be referenced during recipient lookup and risk assessment. Registration alone does not prove identity or authorize payments.

How it could work: The system can collect an email address and required registration details, validate the input, create a unique identity reference and record the verification state. It should prevent duplicate or conflicting registrations and protect personal information.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Current prototype. This label describes the current roadmap position, not a production service guarantee.

What it is: Checks whether a person can demonstrate control of the email address registered to a recipient identity. Email ownership is one trust signal, not proof of legal identity or account ownership.

How it could work: The system can generate a short-lived, single-use verification code and deliver it through an approved email provider. It should limit attempts, expire unused codes, prevent replay and record the verification outcome.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Current prototype. This label describes the current roadmap position, not a production service guarantee.

What it is: Checks whether a recipient can demonstrate control of the phone number assigned to their identity record. The trusted phone number must not be replaceable by the person during the verification process.

How it could work: The phone number should be recorded through an authorized registration or identity-management process. A separate code can then be delivered through an approved messaging provider. Verification should confirm control of that assigned number without treating it as proof of legal identity.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. Email ownership, phone ownership, legal identity and payment authorization must remain separate verification questions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: Requires separate confirmation of both the registered email address and assigned phone number. Completing only one check must never produce a fully verified recipient status.

How it could work: The system can generate independent, securely stored, short-lived codes for each channel. Each code must be delivered and submitted separately, with its own attempt limits and expiry. FULLY_VERIFIED should be reached only when both checks succeed for the same registration.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. Email ownership, phone ownership, legal identity and payment authorization must remain separate verification questions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: Combines the required recipient identity checks into a clear verification status. It distinguishes confirmed email and phone control from legal identity checks and financial account ownership.

How it could work: A verification service can evaluate each required check independently and maintain an auditable status for each. The overall status should reflect exactly which checks passed, failed or remain incomplete. It must not imply payment authorization or guaranteed account ownership.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: Provides risk and identity information to help a financial institution assess whether the intended beneficiary details are consistent with available recipient records before a payment decision.

How it could work: An authorized institution can submit beneficiary details for comparison against permissioned, reliable records. TrustNG can return match indicators, discrepancies, confidence limitations and reasons for review. The institution retains responsibility for confirmation and payment decisions.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: Extends beneficiary checking with more detailed comparisons and risk signals to help identify incorrect, inconsistent or potentially manipulated recipient details.

How it could work: With appropriate provider access and consent, the system can compare submitted recipient information with trusted account-name or identity records. Results should distinguish exact matches, partial matches, mismatches and unavailable information. TrustNG must not claim direct bank verification when no authorized source is connected.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: Allows authorized systems to find a registered TrustNG recipient using an approved identifier, such as a registered email identity or recipient reference.

How it could work: The lookup service can validate the request, search permitted identity records and return only the information the requester is authorized to see. It should use authentication, rate limits, privacy controls and protections against account enumeration.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Current prototype. This label describes the current roadmap position, not a production service guarantee.

What it is: Provides a structured view of the recipient-related trust signals and verification states available to an authorized requester. It is an assessment profile, not a guarantee that a recipient is safe.

How it could work: The profile can combine verified contact-channel states, approved identity checks, relevant risk indicators and recorded changes. Each item should show its source, freshness and limitations, with access restricted to authorized parties.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: Evaluates available information about a financial account to identify trust indicators, inconsistencies or reasons for additional review. It does not independently certify an account or authorize a transaction.

How it could work: The system can assess permissioned account-related signals from approved providers and institutional integrations. It should explain which checks were performed, which sources supplied the data and which checks were unavailable.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Current prototype. This label describes the current roadmap position, not a production service guarantee.

What it is: Helps assess whether available evidence supports a claimed relationship between a recipient and a financial account. Contact-channel verification alone is not sufficient evidence of account ownership.

How it could work: Where an authorized financial institution or account-data provider supplies reliable information, TrustNG can compare the account holder details with the recipient identity record. Results should identify the evidence source, match limitations and unresolved discrepancies.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: Supports checks of a person's claimed legal identity through appropriately authorized identity-verification providers. It is separate from email ownership, phone ownership and payment authorization.

How it could work: An approved provider can perform the relevant identity checks under applicable consent, privacy and regulatory requirements. TrustNG can receive and record the provider's permitted result, source and verification status without claiming to be a government identity authority.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. Email ownership, phone ownership, legal identity and payment authorization must remain separate verification questions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: Identifies material changes to recipient identity information or verification records that may require additional checks before an institution relies on an earlier assessment.

How it could work: The system can compare authorized updates with previous verified records, identify changed fields and record when and where a change occurred. Sensitive changes can generate a review signal rather than automatically approving or rejecting a transaction.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: Maintains an appropriately controlled history of recipient-related risk assessments, verification events and relevant changes to support reviews over time.

How it could work: The system can store timestamped events, source references, assessment reasons and status changes. Retention limits, correction procedures, access controls and data protection must govern what is stored and who can view it.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: Connects TrustNG with approved external identity-verification services so participating institutions can use relevant provider results in their recipient risk assessments.

How it could work: Each integration can authenticate requests, transmit only necessary information, validate provider responses and record the source and time of each result. Provider availability, consent, jurisdictional rules and contractual permissions must be considered.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. Email ownership, phone ownership, legal identity and payment authorization must remain separate verification questions.

Delivery status: Research. This label describes the current roadmap position, not a production service guarantee.

What it is: Notifies authorized users or institutions when important recipient identity or contact details change, allowing them to review changes that could affect trust.

How it could work: The system can monitor approved identity-record updates and send alerts through configured channels. Notifications should identify the type and time of change without unnecessarily exposing sensitive personal information.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: Provides relevant notifications about recipient verification status, unresolved checks or trust-related events to authorized parties.

How it could work: Notifications can be triggered by defined events such as verification completion, expiry, failed checks or a material record change. Delivery should be authenticated, privacy-conscious and auditable, with clear distinctions between information and payment instructions.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: Provides a controlled process for recovering access to a recipient identity when a user loses access to a registered email address or phone. Recovery must not allow an attacker to replace trusted contact details simply by requesting a change.

How it could work: A recovery workflow can require independent evidence, additional checks and review by an authorized provider or institution. It should revoke or expire vulnerable sessions and credentials, record every recovery action and require renewed verification before restoring the relevant trust status.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: Provides a recipient identity linked to a registered email address, allowing participating systems to reference a recipient without exposing their bank account details during initial identification. It is an identity and lookup capability, not a bank account.

How it could work: The system can associate a verified email address with a unique TrustNG recipient reference. Access to the associated record should be permission-controlled, and the identity should be resolvable only through authorized integrations. Financial institutions remain responsible for account selection and payment execution.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: Explores using a registered TrustNG email identity as a convenient recipient identifier instead of requiring a sender to manually enter bank account details at the first stage. The email identity does not itself hold funds or replace the underlying financial account.

How it could work: A participating institution can submit the registered email identity to an authorized resolution service. The service can return permitted recipient information or a secure reference for the institution's own payment workflow. Any bank account resolution must occur through an authorized provider or institution.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Long-term concept. This label describes the current roadmap position, not a production service guarantee.

What it is: Allows an authorized system to resolve a registered email identity to the corresponding TrustNG recipient record and permitted recipient information.

How it could work: The service can normalize and validate the submitted email address, locate the matching registered identity and return a restricted response. Authentication, consent, rate limiting, privacy controls and account-enumeration protections should apply.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: Allows participating systems to request a transaction risk assessment using a recipient's registered email identity as one of the lookup inputs.

How it could work: An authorized client can submit the email identity and relevant transaction context. TrustNG can resolve the recipient reference where permitted, evaluate available risk signals and return an explainable advisory assessment. The result does not authorize, execute or guarantee a payment.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Current prototype. This label describes the current roadmap position, not a production service guarantee.

What it is: Allows a user or participating institution to create a payment request addressed to a registered TrustNG email identity. A request communicates an intended payment; it does not initiate or complete a transfer by itself.

How it could work: The system can create a request record with a unique reference, requester, recipient identity, amount and currency where applicable, expiry and status. The recipient or institution can review it through an authorized channel. Any actual payment must take place separately through the relevant financial institution or payment provider.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. This roadmap item does not mean TrustNG initiates, processes, settles or authorizes payments. Any payment action would remain with the appropriately authorized provider and customer.

Delivery status: Current prototype. This label describes the current roadmap position, not a production service guarantee.

What it is: Aims to let a recipient use a consistent TrustNG identity reference across participating institutions and supported services, reducing dependence on institution-specific identifiers.

How it could work: A controlled identity directory can maintain a stable TrustNG reference and support authorized resolution across integrations. Portability requires explicit permissions, reliable identity matching, jurisdiction-aware privacy controls and safeguards against unauthorized linking of a person's records.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Long-term concept. This label describes the current roadmap position, not a production service guarantee.

What it is: Protects registered email identities against unauthorized registration, takeover, impersonation, enumeration and misuse in recipient lookup or payment-related workflows.

How it could work: Protection can combine ownership verification, secure account recovery, change monitoring, abuse detection, rate limits and access controls. Sensitive identity information should not be disclosed simply because a requester knows an email address.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: Provides a controlled way to recover access to a registered TrustNG email identity when the owner loses access to the associated email account or other registered contact channel.

How it could work: Recovery can require independent evidence and additional verification through approved processes. The system should protect existing identity records during recovery, record every change, invalidate vulnerable sessions and require renewed checks before restoring trust status.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: Provides infrastructure for creating, delivering, tracking and reviewing structured requests for payment between identified parties. It is a request-management capability, not a payment-processing service.

How it could work: The system can record the requester, intended recipient, amount, currency, reference, description, expiry and request status. It can notify the recipient and accept permitted responses such as accepted, declined or expired. Acceptance must not be represented as proof of payment or as authorization to move funds.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. This roadmap item does not mean TrustNG initiates, processes, settles or authorizes payments. Any payment action would remain with the appropriately authorized provider and customer.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: Explores a controlled directory that links verified email addresses or phone numbers to recipient identity references, helping authorized systems identify recipients through familiar contact details.

How it could work: The directory can store verified proxy-to-recipient associations and resolve them only for authenticated, authorized requests. Separate ownership checks, consent, reassignment handling, privacy safeguards and anti-enumeration controls are essential, especially when phone numbers change owners.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: Adds recipient and request integrity checks to payment requests so users and institutions can assess whether a request is consistent with the intended recipient and available trust information.

How it could work: The system can validate the request reference, requester identity, recipient resolution, amount, currency, expiry and relevant risk signals. It can flag inconsistencies and return an advisory result. The financial institution retains responsibility for payment authorization and execution.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. This roadmap item does not mean TrustNG initiates, processes, settles or authorizes payments. Any payment action would remain with the appropriately authorized provider and customer.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: Identifies transaction and account activity that contains indicators associated with possible fraud. It helps participating institutions prioritize suspicious activity for assessment rather than treating every alert as confirmed fraud.

How it could work: The engine can evaluate permissioned transaction data, identity signals, device information, historical patterns and configured rules. It should return explainable indicators, evidence sources and uncertainty. Institutions retain responsibility for investigation and decisions.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: Provides prototype functionality for creating, retrieving and tracking suspected fraud cases during the current application process.

How it could work: Case records and their investigation details are held in the application memory using an in-memory dictionary. They are not currently stored as complete, durable case records in a database, so they do not survive an application restart.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Current prototype. This label describes the current roadmap position, not a production service guarantee.

What it is: Supports authorized investigators as they examine suspected fraud events, review relevant information, identify relationships and document findings.

How it could work: Investigators can view permitted transaction records, risk assessments, timelines, related entities and evidence. The system should distinguish verified facts, reported claims, analytical leads and unresolved questions.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: Allows investigation notes to be added to an in-memory fraud case, with a corresponding event recorded in the local audit JSON file.

How it could work: A note is added to the case held in application memory. A corresponding audit event is also written to the local JSON audit file. The case note itself is not independently stored as a durable database record.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Current prototype. This label describes the current roadmap position, not a production service guarantee.

What it is: Records supported investigation actions against an in-memory fraud case and writes corresponding events to the local audit JSON file.

How it could work: Supported actions update the case held in application memory and create corresponding audit events. Complete case records and action history are not currently maintained in a production-grade database.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Current prototype. This label describes the current roadmap position, not a production service guarantee.

What it is: Allows a prototype fraud case to be marked resolved or dismissed, with the outcome recorded in the in-memory case and a corresponding audit event written to the local JSON file.

How it could work: The resolution updates the case held in application memory and records a corresponding audit event. The case resolution is not currently stored as a durable database record and can be lost when the application restarts.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Current prototype. This label describes the current roadmap position, not a production service guarantee.

What it is: Calculates basic fraud case counts by status and severity from cases currently held in application memory.

How it could work: The current statistics function counts the cases in the in-memory case dictionary. It does not retrieve historical case statistics from the audit JSON file, and its counts reset when the application restarts.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Current prototype. This label describes the current roadmap position, not a production service guarantee.

What it is: Looks for recurring combinations of events or behaviours that may indicate a fraud pattern across transactions, recipients, accounts or other permitted data.

How it could work: Analytical rules and validated models can identify repeated characteristics, unusual sequences and emerging patterns. Findings should include the evidence and limitations, with human review before consequential action.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: Helps identify possible coordinated fraud activity involving multiple accounts, recipients, devices or other connected entities.

How it could work: Where legally permitted data is available, relationship analysis can identify shared attributes, repeated interactions and suspicious network structures. A shared attribute alone is not proof of coordination, so results require context and investigation.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: Highlights recipient records or activity that contain risk indicators requiring further assessment before an institution relies on the available recipient information.

How it could work: The system can evaluate relevant verification states, reported incidents, unusual changes and permissioned risk signals. It should explain the reasons for concern, distinguish allegations from confirmed findings and allow corrections to inaccurate records.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: Provides a controlled framework for participating institutions to exchange relevant fraud indicators and warnings where sharing is lawful, authorized and appropriate.

How it could work: Approved participants can submit structured indicators with source, timestamp, confidence and permitted-use information. Validation, access controls, privacy safeguards, correction mechanisms and governance are necessary to prevent inaccurate or unauthorized intelligence from spreading.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: Produces structured reports that summarize an investigation, its evidence, relevant events, analysis, limitations and recorded outcome for authorized recipients.

How it could work: Reports can be assembled from approved case records and include source references, event timelines and reviewer conclusions. Access restrictions, export controls, accuracy checks and an audit trail should apply.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: Helps investigation teams allocate fraud cases to appropriate reviewers and coordinate responsibilities, workloads and escalation paths.

How it could work: Authorized managers can assign cases using defined roles, expertise, workload or priority. Assignment changes and ownership history should be recorded, with access limited to approved team members.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: Organizes evidence associated with fraud investigations so authorized reviewers can identify its source, context, integrity and relationship to a case.

How it could work: The system can store or reference approved evidence records with timestamps, source details, access history and integrity checks. Evidence handling should preserve originals where required and follow applicable legal, privacy and retention rules.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: Identifies signals that may indicate an account is being accessed or controlled by someone other than its legitimate user.

How it could work: The system can assess unusual login patterns, device changes, credential-reset events, session activity and other permissioned signals. Alerts should explain the indicators and allow the responsible institution to investigate and apply its own account-security controls.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: Identifies account or transaction patterns that may be consistent with the use of an account to receive, hold or move proceeds from suspected financial crime.

How it could work: Analysis can consider unusual incoming and outgoing flows, rapid movement of funds, account relationships and other permitted indicators. These patterns are investigative leads, not proof of criminal conduct, and require appropriate review.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: Highlights transaction circumstances and behavioural signals that may indicate a person is being manipulated or deceived into making a payment.

How it could work: The system can assess available warning signals such as unusual recipient changes, reported scam indicators, suspicious payment context and abnormal activity. It should communicate uncertainty and support timely human intervention without assuming that every unusual payment is a scam.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: Looks for changes or inconsistencies in beneficiary and payment instructions that may indicate an attempt to redirect an intended payment.

How it could work: The system can compare current instructions with previously authorized records, detect unusual beneficiary changes and assess related risk signals. Verification and any decision to hold or reject a payment remain with the responsible institution.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. This roadmap item does not mean TrustNG initiates, processes, settles or authorizes payments. Any payment action would remain with the appropriately authorized provider and customer.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: Identifies combinations of identity information that may indicate a fabricated or manipulated identity assembled from genuine, altered or invented details.

How it could work: Analysis can examine inconsistencies across permissioned identity attributes, provider results, account relationships and behavioural signals. Results should be explainable, carefully validated and subject to human review to reduce unfair treatment of legitimate individuals.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: Assesses available signals about merchants to help institutions understand merchant-related fraud, dispute, identity and operational risks.

How it could work: The system can evaluate permitted merchant information, reported incidents, transaction patterns and verified provider data. Assessments should identify their sources and freshness and should not imply regulatory approval or certification.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: Examines the frequency and timing of transactions or related events to identify activity that differs materially from expected patterns.

How it could work: Configurable windows and thresholds can evaluate counts, values, repetition and related entity activity. Results should account for legitimate usage patterns, data gaps and institution-specific policies.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: Explores a collaborative intelligence capability for identifying possible networks of accounts involved in suspicious movement of funds across participating institutions.

How it could work: With lawful data-sharing agreements and suitable permissions, participating organizations can contribute validated indicators for controlled relationship analysis. Shared signals need provenance, confidence levels, correction processes and safeguards against treating association as proof of wrongdoing.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: Helps institutions identify warning signs that a customer may be at risk of being deceived into authorizing a payment to a scammer.

How it could work: The system can combine recipient checks, payment context, known scam indicators and unusual behavioural signals to produce warnings or review recommendations. The institution controls customer communication, intervention and any payment decision.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. This roadmap item does not mean TrustNG initiates, processes, settles or authorizes payments. Any payment action would remain with the appropriately authorized provider and customer.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: Organizes relevant transaction, recipient, alert and investigation information to support an institution's assessment of fraud-related disputes and reimbursement claims.

How it could work: The system can assemble permitted records, event timelines and investigation references for authorized case handlers. Eligibility, liability, reimbursement decisions and customer remedies remain subject to the responsible institution's policies and applicable law.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Research. This label describes the current roadmap position, not a production service guarantee.

What it is: Explores a coordinated framework through which participating financial organizations can exchange timely, relevant information about significant fraud incidents and emerging threats.

How it could work: Authorized participants can share structured incident notices, indicators and response updates under agreed governance and confidentiality rules. The network should define participant verification, permitted use, escalation contacts, correction procedures and incident-handling responsibilities.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Research. This label describes the current roadmap position, not a production service guarantee.

What it is: Provides AI-assisted analysis of transaction and identity risk signals to help institutions understand suspicious activity and make better-informed risk assessments.

How it could work: The system can combine approved data, configured policies and analytical models to produce risk indicators, explanations and recommendations. Each result should identify relevant evidence and limitations. AI output remains advisory, with authorized institutional personnel and systems retaining decision-making responsibility.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Current prototype. This label describes the current roadmap position, not a production service guarantee.

What it is: Identifies activity that differs significantly from established behaviour patterns and may warrant additional risk assessment.

How it could work: Models can compare current activity with relevant historical patterns, such as transaction timing, frequency, recipient changes and other permitted signals. The system should account for changing legitimate behaviour, data gaps and false positives, and explain which patterns triggered an alert.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: Uses machine learning techniques to identify relationships in historical and current risk data that may help improve transaction risk assessments.

How it could work: Models can be trained and evaluated using appropriately governed datasets with documented labels, features and validation procedures. Performance should be tested on data separate from training, monitored for drift and bias, and compared with simpler rules or baseline models before operational use.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: Analyses available risk signals to estimate whether activity may be associated with emerging or future fraud patterns.

How it could work: Predictive models can use validated historical outcomes, transaction characteristics and permitted relationship signals to estimate risk. Predictions should include uncertainty, be evaluated against real outcomes and be monitored for changing fraud patterns. They are indicators for review, not proof that fraud has occurred.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: Explores ways for TrustNG risk intelligence to respond to changing fraud patterns, new evidence and evolving institutional risk requirements.

How it could work: Approved updates to rules, model parameters or intelligence sources can be evaluated against historical and test scenarios before adoption. Changes should be versioned, measured and reviewed by authorized people, with rollback options and safeguards against unvalidated automatic changes.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: Makes AI-assisted risk assessments easier to understand by showing the factors, evidence and limitations that contributed to an output.

How it could work: Each assessment can provide reason codes, relevant signals, model or policy versions and an explanation appropriate to the intended user. Explanations should accurately reflect how the system produced the result and avoid presenting correlations or model estimates as proven causes.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: Uses AI-assisted analysis to help assess recipient-related information, verification signals and relevant risk patterns.

How it could work: The capability can examine permitted recipient records, verification states, changes and historical risk indicators. It should distinguish verified information from unconfirmed reports, identify data freshness and uncertainty, and allow authorized reviewers to investigate or correct inaccurate information.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: Helps authorized investigators review fraud cases by organizing information, summarizing relevant records and identifying possible investigative leads.

How it could work: The assistant can summarize approved case material, build event timelines, highlight relationships and suggest questions for further investigation. It should cite the underlying records, distinguish facts from suggestions and require human review before findings or case outcomes are recorded.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: Supports controlled research into fraud trends, risk patterns, model behaviour and possible improvements to TrustNG's intelligence capabilities.

How it could work: The assistant can help analyze approved datasets, compare research results, summarize documented findings and propose experiments. Research outputs should be reproducible, traceable to their sources and reviewed before any finding is promoted into a production rule or model.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: Explores an AI-assisted interface for developers and authorized operators to understand TrustNG status, inspect permitted diagnostics and work with technical documentation.

How it could work: The assistant can explain API responses, summarize approved logs, help interpret test results and suggest commands or troubleshooting steps. Access should follow existing permissions, sensitive values should be protected, and potentially destructive commands or operational changes must require explicit authorization.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: Tracks the reliability and behaviour of AI and machine learning models so that performance problems, drift and unexpected outputs can be identified.

How it could work: Monitoring can compare model predictions with subsequently verified outcomes, track error rates and calibration where measurable, and examine changes in input data. Reports should include model versions, evaluation periods and known limitations, with defined review and rollback procedures.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: Ensures that AI-generated risk assessments and recommendations remain subject to appropriate human supervision, accountability and institutional controls.

How it could work: Authorized reviewers can inspect explanations, challenge outputs, record decisions and escalate uncertain cases. Permissions, review thresholds, override records and audit trails should be defined. Human oversight must be meaningful rather than a simple approval step for an unexplained automated result.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: Explores the use of bounded AI agents to assist with payment-security workflows such as gathering risk context, checking permitted information and preparing recommendations.

How it could work: Agents should operate within narrowly defined permissions and approved tools, with clear limits on data access and actions. They may prepare assessments or request human review, but must not independently authorize, initiate, execute or move funds. Actions and tool use should be logged, monitored and subject to explicit institutional controls.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. This roadmap item does not mean TrustNG initiates, processes, settles or authorizes payments. Any payment action would remain with the appropriately authorized provider and customer.

Delivery status: Long-term concept. This label describes the current roadmap position, not a production service guarantee.

What it is: Connects permitted information about accounts, recipients, devices, transactions and other entities to help reveal relationships that may be relevant to financial risk assessment.

How it could work: A graph model can represent entities as nodes and verified or observed relationships as edges. Each relationship should carry its source, timestamp, confidence and permitted-use context. Graph findings should support investigation and risk assessment, not treat a connection as proof of fraud.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: Shows relevant connections between financial entities so authorized users can understand how accounts, recipients, devices and transactions may be related.

How it could work: The system can build visual or structured relationship maps from approved records and data sources. Users should be able to inspect why each connection exists, when it was observed and how reliable it is, with access and privacy controls applied.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: Identifies accounts that may be connected through shared or repeated attributes, activity or other permitted relationship signals.

How it could work: Analysis can compare approved identifiers, account activity, recipient relationships and verified provider signals. Shared details may have legitimate explanations, so the system should show the evidence and confidence behind each connection and avoid assuming common ownership or wrongdoing.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: Assesses device-related signals that may help identify unusual connections between accounts or suspicious patterns of access and activity.

How it could work: Where lawful and consented device information is available, the system can identify repeated device associations, changes and unusual usage patterns. Device sharing can be legitimate, so findings should be contextual, proportionate and subject to review.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: Examines relationships across connected entities to identify network patterns that may be associated with coordinated or repeated fraudulent activity.

How it could work: Graph analysis can search for unusual clusters, repeated interactions, common attributes and suspicious transaction paths. Results should include the underlying relationships and their provenance, while accounting for legitimate shared infrastructure and other innocent explanations.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: Examines how transactions relate to one another through shared recipients, accounts, entities, timing or other permitted information.

How it could work: The system can connect relevant transaction records into timelines and relationship structures, highlighting repeated flows, unusual sequences or common participants. It should preserve transaction references, data sources and timestamps so investigators can verify the analysis.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: Assesses recipient-related risk using relevant connections and patterns across a permitted network of accounts, recipients and reported activity.

How it could work: A recipient assessment can consider verified identity information, relevant transaction relationships and validated risk indicators. It should distinguish direct evidence from indirect associations, account for stale information and allow authorized correction or review.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: Compares permitted activity across related accounts to identify patterns that may not be visible when each account is assessed independently.

How it could work: The capability can analyze shared recipients, transaction timing, repeated behaviours and other authorized signals across accounts. It must enforce data access boundaries, minimize unnecessary personal information and distinguish meaningful patterns from coincidental similarities.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: Produces an analytical assessment of network-related risk based on the quality, relevance and reliability of permitted relationships and signals.

How it could work: A scoring model can combine relationship strength, evidence quality, source reliability, recency and validated risk indicators. The output should explain its contributing factors and uncertainty, avoid guilt by association and remain advisory to authorized institutions.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: Provides an integration interface through which authorized institutions and developers can request relevant network-based risk intelligence.

How it could work: An API request can submit permitted entity references or transaction context and return relevant relationship indicators, risk explanations and data limitations. Authentication, authorization, tenant separation, rate limits, data minimization and audit logging should protect the service.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: Builds a broader understanding of account activity by analyzing relevant historical patterns, changes and relationships over time.

How it could work: The system can evaluate permitted transaction history, recipient interactions, account changes and related behavioural signals. Assessments should identify the period and evidence used, account for legitimate changes and avoid making unsupported claims about the account holder.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: Provides timely alerts about emerging threats or suspicious patterns identified across a permitted financial intelligence network.

How it could work: Alerts can be generated when validated indicators, unusual network patterns or significant incident reports meet defined thresholds. Each alert should include its source, timestamp, confidence, affected scope and recommended review steps, with controlled distribution and correction procedures.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Long-term concept. This label describes the current roadmap position, not a production service guarantee.

What it is: Assesses transaction and recipient risk using relevant intelligence from participating financial institutions, subject to lawful access and data-sharing permissions.

How it could work: Participating institutions may contribute permitted risk signals through controlled integrations. TrustNG can combine eligible signals into advisory assessments while preserving each institution's access rules and decision-making authority.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: Supports responsible sharing of fraud indicators and confirmed threat patterns between participating institutions.

How it could work: Institutions can submit and receive approved indicators with source attribution, confidence context and appropriate access controls. Shared intelligence informs risk assessments rather than independently determining transaction outcomes.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: Provides a broader risk view of recipient identifiers using lawfully accessible information from participating banks.

How it could work: Where institutions have appropriate permission to share relevant signals, TrustNG can correlate recipient references and identify inconsistencies or known risk indicators. Each institution retains control of its own customer data and decisions.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: Evaluates transaction-related risk across countries using relevant geographic, institutional, identity and behavioural signals.

How it could work: The assessment can consider the countries and institutions involved, available identity evidence, corridor patterns and applicable risk indicators. Results remain advisory and should reflect the limitations of available data.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Research. This label describes the current roadmap position, not a production service guarantee.

What it is: Analyses risk patterns associated with financial corridors connecting countries, regions and participating institutions.

How it could work: TrustNG can examine permitted aggregate corridor activity, unusual patterns and known risk indicators to help institutions understand corridor-specific exposure without processing or moving funds.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Research. This label describes the current roadmap position, not a production service guarantee.

What it is: Provides contextual country-level risk indicators relevant to cross-border financial activity and recipient assessments.

How it could work: The system can organise sourced indicators such as jurisdictional exposure, documented fraud patterns and applicable restrictions, recording their origin and freshness. Country context is one input, not a judgement about an individual.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: Examines risk signals associated with currencies and supported financial asset types in a transaction context.

How it could work: TrustNG can use configured asset classifications, currency context, volatility indicators where relevant and known exposure signals to enrich an assessment. It does not exchange, hold or transfer currencies or assets.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: Allows each participating institution to define risk thresholds, rules and assessment preferences suited to its own obligations and operating environment.

How it could work: Authorised institution administrators can configure and version policy settings within controlled boundaries. TrustNG applies the configured criteria to advisory assessments and records which policy context was used.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: Organises relevant fraud, identity and financial risk indicators by region to support locally informed assessments.

How it could work: Permitted data and sourced indicators can be grouped by region and monitored for changes in patterns. Regional context can improve interpretation without treating every country or community as having the same risk profile.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: Combines relevant international risk indicators to support consistent, context-aware assessments across participating markets.

How it could work: TrustNG can bring together appropriately sourced country, institution, corridor and threat intelligence, while tracking provenance, freshness and coverage limitations. Outputs help authorised teams review risk; they do not authorise transactions.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Research. This label describes the current roadmap position, not a production service guarantee.

What it is: Supports assessment of identity and recipient trust evidence across jurisdictions and participating verification providers.

How it could work: With appropriate consent and lawful provider access, TrustNG can evaluate verification results, issuer context and consistency between permitted identity signals. A successful check does not by itself establish legal identity or payment authorisation.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Research. This label describes the current roadmap position, not a production service guarantee.

What it is: Provides a structured, permission-controlled summary of relevant risk and trust signals that can be evaluated across participating institutions and jurisdictions.

How it could work: A subject or authorised institution may share an appropriately scoped record with a receiving party under defined permissions. The receiving institution evaluates the evidence independently; the passport is not a universal identity credential, credit approval or transaction authorisation.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Long-term concept. This label describes the current roadmap position, not a production service guarantee.

What it is: Supports consistent exchange and interpretation of permitted financial risk intelligence across systems, institutions and jurisdictions.

How it could work: Integration adapters and agreed data formats can map compatible indicators while preserving source provenance, consent, jurisdictional restrictions and institution-specific controls. Interoperability supports assessment only and does not grant access to restricted data.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Research. This label describes the current roadmap position, not a production service guarantee.

What it is: Compares available transaction records and status evidence to identify mismatches, missing confirmations and unresolved outcomes.

How it could work: TrustNG can compare permitted records from connected systems using transaction references, timestamps and status information. Differences can be flagged for investigation, with the evidence and reconciliation state retained for review.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Current prototype. This label describes the current roadmap position, not a production service guarantee.

What it is: Tracks transactions reported as pending or awaiting reliable status confirmation so unresolved cases remain visible.

How it could work: The system can monitor pending records against configured time limits and permitted status updates. It can raise alerts when a transaction remains unresolved, without treating a pending state as proof of success or failure.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Current prototype. This label describes the current roadmap position, not a production service guarantee.

What it is: Identifies cases where available evidence does not establish whether a transaction reached its intended final state.

How it could work: TrustNG can evaluate conflicting, incomplete or delayed status signals and classify the outcome as uncertain. It can recommend reconciliation and prevent an uncertain result from being presented as confirmed success.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: Organises unresolved transaction discrepancies into traceable cases for authorised operational teams.

How it could work: A case can contain transaction references, observed status changes, timestamps, evidence, assigned reviewers and resolution notes. Teams can investigate and record outcomes without TrustNG independently executing or reversing transactions.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: Records selected fraud investigation events in a local JSON file, providing basic event persistence for prototype review.

How it could work: Audit events are appended to a local JSON file with a storage timestamp. This provides basic file-based persistence, but does not establish a production-grade, immutable or independently protected audit service. File access, concurrent writes, backups and retention require stronger controls.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Current prototype. This label describes the current roadmap position, not a production service guarantee.

What it is: Recalculates SHA-256 fingerprints to identify audit events whose recorded content no longer matches their stored fingerprint.

How it could work: The verification routines recalculate event fingerprints and report missing or mismatched fingerprints. This can reveal certain changes, but the fingerprints are stored alongside the events and can also be recalculated after alteration. The mechanism does not prevent tampering, independently prove record history or guarantee that the original information was accurate.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Current prototype. This label describes the current roadmap position, not a production service guarantee.

What it is: Checks whether reported transaction states follow defined lifecycle rules and are supported by available evidence.

How it could work: TrustNG can compare incoming status updates with permitted state transitions, expected references and prior observations. Invalid or contradictory transitions can be flagged for review rather than silently accepted.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: Identifies potentially repeated transaction records or requests that may represent duplicate processing or reporting.

How it could work: The system can compare stable references, idempotency keys, timestamps and relevant transaction attributes to identify likely duplicates. A duplicate alert is an assessment signal, not an instruction to cancel or reverse a payment.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: Provides structured transaction evidence and history to support authorised dispute handling and investigations.

How it could work: TrustNG can organise relevant records, status history, risk signals and audit events into a reviewable evidence summary. Decisions about disputes, refunds or other financial actions remain with the responsible institution.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: Assesses the reliability and consistency of payment status information received from permitted sources.

How it could work: The system can distinguish reported, pending, confirmed, failed and uncertain states based on source quality and available evidence. A confirmation is only as reliable as its originating provider and evidence; TrustNG does not itself confirm that funds moved.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. This roadmap item does not mean TrustNG initiates, processes, settles or authorizes payments. Any payment action would remain with the appropriately authorized provider and customer.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: Assesses risks associated with escrow arrangements, including buyer and seller trust signals, transaction conditions and available evidence.

How it could work: TrustNG can evaluate permitted party information, transaction context, stated conditions and relevant risk indicators to produce an advisory assessment. It does not receive, hold or control escrow funds.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. Any escrow or release activity would require appropriately licensed providers and valid legal arrangements. TrustNG itself is not a custodian.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: Tracks reported escrow milestones and status information so parties and authorised teams can identify delays, inconsistencies or unresolved conditions.

How it could work: The system can collect permitted status updates from an escrow provider or connected system, record their sources and timestamps, and flag missing or contradictory information. Monitoring does not mean TrustNG operates the escrow arrangement.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. Any escrow or release activity would require appropriately licensed providers and valid legal arrangements. TrustNG itself is not a custodian.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: Assesses whether available evidence appears consistent with the conditions defined for a proposed transaction or escrow arrangement.

How it could work: TrustNG can compare documented conditions with permitted confirmations, identity signals and milestone evidence. It reports matches, gaps and uncertainties for authorised review; it does not independently approve or execute a release.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: Evaluates risk signals and available evidence before an authorised escrow provider or responsible party considers a funds-release instruction.

How it could work: The assessment can review party trust, reported milestones, unresolved disputes, status consistency and configured risk rules. Its output is advisory; the escrow provider or legally authorised party retains release authority.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. Any escrow or release activity would require appropriately licensed providers and valid legal arrangements. TrustNG itself is not a custodian.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: Organises dispute-related risk signals and transaction evidence to support fair, traceable review of escrow disagreements.

How it could work: TrustNG can assemble relevant status history, agreed conditions, communications metadata where lawfully available, and investigation records. It can highlight inconsistencies but does not decide legal liability or settle disputes.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: Provides separate, evidence-based risk profiles for buyers and sellers using permitted identity, behaviour and transaction-related signals.

How it could work: Each profile can present relevant verification status, historical risk indicators, evidence freshness and known limitations. Profiles should be purpose-limited, access-controlled and explainable, and must not be treated as a guarantee that a party is safe.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: Provides developers with documented interfaces for integrating TrustNG risk-assessment capabilities into their applications and financial systems.

How it could work: Developers can submit permitted transaction or recipient context through authenticated API endpoints and receive structured advisory results. Versioning, validation, consistent response formats and access controls support reliable integration.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Current prototype. This label describes the current roadmap position, not a production service guarantee.

What it is: Provides controlled creation, rotation, revocation and monitoring of credentials used to access TrustNG APIs.

How it could work: Authorised administrators can issue credentials with defined scopes, associate them with institutions or applications, and revoke or rotate them when necessary. Secrets should be stored securely and never exposed in client-side code or logs.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: Supports administration of participating financial institutions and their authorised organisational accounts.

How it could work: An institution onboarding workflow can maintain organisation details, account status, approved integrations and designated administrators. Access to institutional records remains separated and controlled.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: Restricts platform capabilities and sensitive information according to each user's assigned organisational role and permissions.

How it could work: Administrators can assign roles such as developer, analyst, investigator and auditor, with least-privilege permissions. Access checks are enforced on protected operations and sensitive records, with relevant changes audited.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: Provides an isolated environment where developers can test API integrations using simulated data and non-production credentials.

How it could work: Sandbox requests can return clearly labelled simulated outcomes and test scenarios without connecting to real payment rails or moving funds. Sandbox credentials and data remain separate from production.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Current prototype. This label describes the current roadmap position, not a production service guarantee.

What it is: Gives developers access to API references, integration guidance, authentication requirements and example requests and responses.

How it could work: Documentation can be organised by API version and capability, with clear parameter definitions, error explanations, security guidance and sandbox examples. Published examples should reflect actual supported behaviour.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Current prototype. This label describes the current roadmap position, not a production service guarantee.

What it is: Allows connected systems to receive event notifications about relevant TrustNG assessment and monitoring events.

How it could work: Institutions can register authorised HTTPS endpoints and subscribe to permitted event types. Signed notifications, retry controls, event identifiers and replay protection help receiving systems validate and process messages safely.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: Provides visibility into the availability, performance and reliability of connected institutional systems and API integrations.

How it could work: TrustNG can track permitted health signals, response times, error rates and delivery outcomes, then surface failures or unusual changes to authorised operators. Monitoring does not imply control over external systems.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Research. This label describes the current roadmap position, not a production service guarantee.

What it is: Connects TrustNG to supported payment-provider interfaces to obtain permitted transaction context and status evidence for risk assessment.

How it could work: Provider adapters can validate incoming messages, normalise supported fields and preserve source information. Integrations supply evidence for advisory analysis; TrustNG does not initiate, route or execute payments through these connections.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. This roadmap item does not mean TrustNG initiates, processes, settles or authorizes payments. Any payment action would remain with the appropriately authorized provider and customer.

Delivery status: Research. This label describes the current roadmap position, not a production service guarantee.

What it is: Supports secure connections with participating banking systems where access is authorised and technically supported.

How it could work: Integration adapters can exchange permitted identity, account-reference, transaction-status or risk data using agreed interfaces and security controls. Each institution retains authority over its systems, customer information and financial operations.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Research. This label describes the current roadmap position, not a production service guarantee.

What it is: Structures TrustNG integrations to understand relevant message formats and transaction context across supported payment rails.

How it could work: Adapters can map rail-specific identifiers, status values and message fields into a consistent internal representation while retaining original source context. Compatibility supports assessment and monitoring, not payment initiation or settlement.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. This roadmap item does not mean TrustNG initiates, processes, settles or authorizes payments. Any payment action would remain with the appropriately authorized provider and customer.

Delivery status: Research. This label describes the current roadmap position, not a production service guarantee.

What it is: Checks the operational health of individual integrations and identifies connection failures, degraded performance or data-quality issues.

How it could work: Configured checks can track endpoint availability, authentication failures, latency, message delivery and schema changes. Alerts help authorised teams investigate integration problems before relying on incomplete signals.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Research. This label describes the current roadmap position, not a production service guarantee.

What it is: Allows authorised institutions to configure their own risk thresholds, assessment rules and operational preferences.

How it could work: Institution administrators can manage scoped configuration with validation, version history and approval controls. Assessments can identify the configuration applied, while the institution retains responsibility for its policies and decisions.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: Enables TrustNG to serve multiple financial institutions while keeping their users, configurations, credentials and permitted data logically separated.

How it could work: Institution identifiers and access policies can scope API requests, stored records and administrative operations. Cross-institution intelligence is only available where lawful sharing permissions and explicit controls allow it.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: Provides a structured process for registering institutions, validating integration requirements and enabling authorised access to TrustNG.

How it could work: Onboarding can capture organisational information, verify designated contacts, establish credentials, configure permissions and test integrations in a sandbox before any approved production activation.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: Protects institutional information by enforcing tenant boundaries across data access, processing, configuration and reporting.

How it could work: Tenant-aware authorisation and storage controls can ensure that users access only records belonging to their institution unless a specific lawful sharing arrangement permits otherwise. Isolation should be tested and audited continuously.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: Uses appropriately consented and authorised open-banking data to enrich recipient, account and transaction risk assessments.

How it could work: Where supported providers and legal permissions exist, TrustNG can evaluate selected account or transaction information, record consent scope and freshness, and identify relevant patterns. It does not access accounts without authorisation or initiate payments.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Research. This label describes the current roadmap position, not a production service guarantee.

What it is: Coordinates permission-aware access to supported financial data sources for broader risk and trust assessments.

How it could work: The hub can record consent scope, data-source permissions, expiry and revocation, then request only authorised information from connected providers. Data use remains purpose-limited, traceable and subject to applicable jurisdictional requirements.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Research. This label describes the current roadmap position, not a production service guarantee.

What it is: A central operational view of TrustNG service activity, system health, integration status, risk assessments and outstanding operational issues. It presents available operational data without implying that TrustNG executes or authorizes payments.

How it could work: The dashboard could combine API activity, service health checks, integration events, assessment volumes and reconciliation indicators. Access would be role-controlled, with institution-specific views where applicable.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Current prototype. This label describes the current roadmap position, not a production service guarantee.

What it is: A focused view of transaction risk assessments, risk levels, decision recommendations, risk signals and emerging patterns across permitted data.

How it could work: It could aggregate assessment results over selected periods, display risk distributions and allow authorized users to inspect the explanations behind individual assessments.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: A statistical overview of recorded fraud indicators, suspicious activity patterns, investigation cases and case outcomes available to an authorized institution.

How it could work: It could present trends by category, time period and institution using recorded and appropriately classified data. Indicators would not be presented as confirmed fraud unless independently established.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: A workspace for reviewing TrustNG research activity, candidate improvements, evaluation results, benchmarks and proposed changes to risk intelligence capabilities.

How it could work: It could organize research candidates by status, evidence, evaluation results and review history, keeping experimental work separate from active production policies.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Current prototype. This label describes the current roadmap position, not a production service guarantee.

What it is: A controlled review process for proposed models, rules, detection methods and other research candidates before they can be considered for operational use.

How it could work: Reviewers could inspect evidence, test results, limitations and version history, then approve, reject or request further evaluation. Approval would not automatically deploy a candidate.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Current prototype. This label describes the current roadmap position, not a production service guarantee.

What it is: Governance controls for moving an evaluated research candidate into a designated testing or operational environment.

How it could work: Promotion could require authorized human approval, passing tests, documented evidence, version tracking and a defined rollback path. Deployment would remain a separate controlled action.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Current prototype. This label describes the current roadmap position, not a production service guarantee.

What it is: A record of measured system performance, capacity, reliability and resource usage under defined test conditions.

How it could work: Benchmark runs could capture test configuration, workload, response times, throughput and resource consumption. Results would be dated and compared against previous runs without presenting test results as guaranteed production performance.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Current prototype. This label describes the current roadmap position, not a production service guarantee.

What it is: A structured register of proposed improvements to TrustNG features, architecture, security, reliability and developer experience.

How it could work: Each proposal could include its rationale, expected benefit, risks, dependencies, priority, review status and implementation history. Proposals would require review before work is approved.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: Analytical views of transaction-related records and risk assessments available to an authorized institution, including volumes, patterns, statuses and assessment outcomes.

How it could work: It could aggregate permitted records by time period, currency, channel or risk category while applying access controls and data minimization. Analytics would describe available records rather than claim that TrustNG processed or moved funds.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: Structured reports that help participating institutions review their own permitted risk-assessment activity, operational indicators and relevant trends.

How it could work: Reports could be generated for selected periods and institution-defined categories, with institution-level data separation, role-based access and an auditable record of report generation.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: Analysis of how recorded risk indicators, assessment outcomes and suspicious patterns change over time.

How it could work: It could compare historical periods, identify significant changes and highlight areas for further investigation. Trends would be indicators for review, not proof of fraud or predictions guaranteed to occur.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: Controlled export of permitted dashboard information and analytical reports for institutional review, recordkeeping and further analysis.

How it could work: Authorized users could export approved formats such as CSV or PDF, with scope restrictions, sensitive-data handling, access checks and audit records for export activity.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: Monitoring of TrustNG service availability, API response times, error rates and other measurable service-level indicators.

How it could work: It could collect service telemetry, compare measurements against defined service objectives and generate operational alerts. TrustNG service metrics would remain separate from external bank, payment-provider or transaction completion outcomes.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: A notification capability for delivering relevant operational alerts, risk-related updates and service notices to authorized institutional users.

How it could work: Notifications could be triggered by configured events and delivered through approved channels, with recipient permissions, severity levels, delivery records and controls to prevent sensitive information from being exposed.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: A layered API security capability designed to protect TrustNG endpoints against unauthorised access, malicious requests and common application-layer attacks.

How it could work: It could combine strong authentication, request validation, scoped permissions, secure transport, abuse detection and security event logging, with controls tested before release.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: Protection for sensitive information through encryption while data is transmitted and, where appropriate, while stored.

How it could work: It could use modern, well-maintained cryptographic standards, managed keys, defined rotation procedures and encrypted connections between supported services.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: Controls intended to reduce unnecessary exposure of personal, financial and authentication-related information across TrustNG systems.

How it could work: It could classify sensitive fields, minimise collection, mask values in interfaces and logs, restrict access, and apply retention and deletion rules.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: A controlled approach to storing, accessing, rotating and revoking API keys, database credentials, signing keys and other system secrets.

How it could work: It could use a dedicated secrets manager, scoped service identities, rotation schedules, access logs and procedures for responding to exposed credentials.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: Protection against excessive requests, automated abuse and resource exhaustion across public and authenticated endpoints.

How it could work: It could apply configurable limits by API key, institution, route or network signal, with throttling, temporary restrictions and auditable security alerts.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: Operational visibility into application health, errors, resource use, security events and important background processes.

How it could work: It could collect structured metrics and logs, evaluate defined alert thresholds and notify authorised operators when investigation or intervention is needed.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: An architectural approach intended to reduce service disruption when individual application components or infrastructure resources fail.

How it could work: It could use redundant service instances, health checks, controlled traffic routing and tested recovery procedures, subject to the capabilities of the hosting environment.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Research. This label describes the current roadmap position, not a production service guarantee.

What it is: A planned capability for protecting recoverable system data and restoring essential services after data loss, infrastructure failure or other serious incidents.

How it could work: It could combine encrypted backups, defined recovery objectives, restricted backup access and scheduled restoration exercises to verify that backups actually work.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: Testing intended to measure how TrustNG behaves under expected traffic, peak demand and unusually heavy request volumes.

How it could work: It could run repeatable load and stress tests, measure latency and error rates, identify bottlenecks and compare results against documented performance targets.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: A structured programme for identifying weaknesses in application code, dependencies, APIs, configuration and deployment processes.

How it could work: It could combine automated scanning, dependency checks, authentication and authorisation tests, targeted manual reviews and tracked remediation.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: An independent assessment of TrustNG security controls, architecture, implementation and operational practices by suitably qualified external reviewers.

How it could work: It could provide reviewers with an agreed scope and controlled test environment, document findings and track corrective actions through independent retesting.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Research. This label describes the current roadmap position, not a production service guarantee.

What it is: Policies and technical controls for responsible collection, use, sharing, retention and deletion of information handled by TrustNG.

How it could work: It could define data ownership, lawful processing requirements, access roles, retention schedules, consent records where applicable and procedures for handling privacy requests.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: A programme for assessing applicable legal, regulatory and supervisory requirements across the markets and institutions TrustNG may support.

How it could work: It could maintain a jurisdiction-specific obligations register, map requirements to controls, preserve evidence and identify gaps for qualified legal and compliance review; readiness would not itself mean regulatory approval.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Research. This label describes the current roadmap position, not a production service guarantee.

What it is: Traceable records of important administrative, configuration, access and operational actions performed within TrustNG.

How it could work: It could record who performed an action, when it occurred, the affected resource and the outcome, while protecting audit records against unauthorised alteration.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: A proposed capability for representing and evaluating structured financial instructions and their conditions without treating TrustNG as the party that executes payments.

How it could work: It could validate instruction fields, assess associated risk and produce advisory results for an authorised external system; any execution would remain with the relevant institution or payment provider.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. This roadmap item does not mean TrustNG initiates, processes, settles or authorizes payments. Any payment action would remain with the appropriately authorized provider and customer.

Delivery status: Long-term concept. This label describes the current roadmap position, not a production service guarantee.

What it is: A proposed capability for checking the integrity of digitally signed records and evidence that a required consent action was recorded.

How it could work: It could validate signatures against trusted keys, check document integrity, record consent scope and time, and flag expired, invalid or withdrawn permissions.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: A proposed risk-intelligence capability for evaluating selected trust and integrity signals associated with tokenised assets and related transactions.

How it could work: It could assess available issuer, ownership, provenance, contract and transaction signals, disclose data limitations and return advisory risk findings without custody or asset-transfer authority.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. TrustNG is designed as risk-intelligence and decision support. It does not hold customer funds, move money or independently authorize or block bank transactions.

Delivery status: Research. This label describes the current roadmap position, not a production service guarantee.

What it is: A proposed capability for assessing risk signals and consent conditions associated with variable or recurring payment arrangements.

How it could work: It could check available mandate details, permitted limits, frequency, changes and revocation status, then return advisory findings to the institution responsible for payment processing.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. This roadmap item does not mean TrustNG initiates, processes, settles or authorizes payments. Any payment action would remain with the appropriately authorized provider and customer.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: A proposed QR-based payment safety capability focused on checking the integrity and risk context of payment information encoded in a QR code.

How it could work: It could validate supported QR formats, resolve recipient or merchant details through approved integrations, detect altered or suspicious payment information and provide a risk assessment before the payer proceeds through their payment provider.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. This roadmap item does not mean TrustNG initiates, processes, settles or authorizes payments. Any payment action would remain with the appropriately authorized provider and customer.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: A proposed capability for assessing risk across transactions that divide an intended amount among multiple recipients or payment instructions.

How it could work: It could examine available relationships between recipients, amounts, timing and shared transaction context to identify unusual patterns and provide advisory findings without initiating or distributing funds.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. This roadmap item does not mean TrustNG initiates, processes, settles or authorizes payments. Any payment action would remain with the appropriately authorized provider and customer.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.

What it is: A proposed capability for identifying transaction patterns and activity that may warrant review under applicable anti-money-laundering controls.

How it could work: It could evaluate available transaction data against configurable rules and risk indicators, identify unusual patterns, explain relevant signals and refer potential concerns to authorised compliance personnel.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. Screening results would be decision-support signals, not a substitute for a regulated institution's legal duties or compliance decisions.

Delivery status: Research. This label describes the current roadmap position, not a production service guarantee.

What it is: A proposed integration capability for checking relevant individuals, organisations or other supported entities against recognised sanctions data sources.

How it could work: It could compare available identity information with licensed or otherwise authorised screening lists, handle potential matches for human review and record the source and time of each check.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. Screening results would be decision-support signals, not a substitute for a regulated institution's legal duties or compliance decisions.

Delivery status: Research. This label describes the current roadmap position, not a production service guarantee.

What it is: A proposed screening capability for identifying potential politically exposed person relationships and associated risk indicators using approved information sources.

How it could work: It could compare identity attributes with permitted PEP datasets, distinguish possible matches from confirmed matches and support enhanced review without automatically determining a customer's legal status.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. Screening results would be decision-support signals, not a substitute for a regulated institution's legal duties or compliance decisions.

Delivery status: Research. This label describes the current roadmap position, not a production service guarantee.

What it is: A proposed capability for finding and analysing relevant adverse media signals associated with people, organisations or other entities being assessed.

How it could work: It could process authorised news and media sources, identify relevant allegations or reported events, assess source reliability and present dated evidence for human assessment rather than treating every mention as proof of wrongdoing.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. Screening results would be decision-support signals, not a substitute for a regulated institution's legal duties or compliance decisions.

Delivery status: Research. This label describes the current roadmap position, not a production service guarantee.

What it is: A proposed workflow capability to help authorised compliance teams organise evidence and prepare information relevant to suspicious activity reporting obligations.

How it could work: It could assemble linked transaction records, risk indicators, investigation notes and timelines into reviewable case material, with access controls and audit records; any decision to submit a report would remain with the responsible institution and its authorised personnel.

Who benefits: Financial institutions, payment providers, developers, risk teams or customers, depending on the use case.

Dependencies: Reliable data, appropriate permissions, security controls, partner access and testing. Screening results would be decision-support signals, not a substitute for a regulated institution's legal duties or compliance decisions.

Delivery status: Planned. This label describes the current roadmap position, not a production service guarantee.