Legal claims defining the scope of protection. Each claim is shown in both the original legal language and a plain English translation.
1. A computer-implemented method comprising: receiving a transaction object corresponding to a payment transaction, wherein the transaction object comprises transaction details, addenda data, and transaction metadata, and wherein the transaction metadata comprises: an indication of a workflow corresponding to a transaction type of the transaction object, wherein the workflow corresponding to the transaction type comprises a plurality of processing steps required to validate a given transaction of the transaction type; and a current workflow stage of the transaction object; adding the transaction object to a streaming data platform, wherein adding the transaction object to the streaming data platform comprises setting the current workflow stage of the transaction object to an initialization stage; polling, by a snapshot microservice, the streaming data platform to retrieve transactions matching the initialization stage, wherein the initialization stage is associated with the snapshot microservice; retrieving, by the snapshot microservice and from the streaming data platform, the transaction object based on the current workflow stage matching the initialization stage; storing, by the snapshot microservice, snapshot data corresponding to the transaction object; updating the current workflow stage of the transaction object to a next workflow stage based on completing storing, by the snapshot microservice, the snapshot data corresponding to the transaction object; retrieving, by a first microservice and from the streaming data platform, the transaction object based on the current workflow stage matching a first workflow stage, wherein the first workflow stage is associated with the first microservice based on the workflow corresponding to the transaction type; processing, by the first microservice, the transaction object to modify the addenda data; determining, by the snapshot microservice and via the streaming data platform, that at least one value associated with the addenda data of the transaction object has changed after the transaction object has left the initialization stage; storing, by the snapshot microservice, snapshot data corresponding to the changed at least one value associated with the addenda data; determining that the processing, by the first microservice, of the transaction object did not complete successfully; causing the first microservice to repeat processing of the transaction object based on the snapshot data corresponding to the transaction object from prior to the start of the processing by the first microservice, wherein causing the first microservice to repeat processing of the transaction object comprises: regenerating, by the snapshot microservice, the transaction object based on the snapshot data corresponding to the transaction object from prior to the start of the processing by the first microservice; and returning the regenerated transaction object to the streaming data platform, wherein a current workflow stage of the regenerated transaction object is set to the first workflow stage; determining that the current workflow stage of the transaction object indicates that the transaction object has completed processing corresponding to the workflow; and removing the transaction object from the streaming data platform and outputting the transaction object and an indication that the transaction object has completed the processing corresponding to the workflow to a downstream system.
2. The method of claim 1 , wherein determining that the at least one value associated with the addenda data of the transaction object has changed comprises: retrieving, by the snapshot microservice and from the streaming data platform, the transaction object.
A system and method for detecting changes in transaction data within a distributed computing environment. The technology addresses the challenge of efficiently tracking modifications to transaction objects in real-time, particularly in systems where data is distributed across multiple services and platforms. The method involves monitoring transaction objects stored in a streaming data platform to detect changes in their associated addenda data. When a change is detected, the system triggers an update process to ensure data consistency across the distributed system. The process includes retrieving the transaction object from the streaming data platform, analyzing its addenda data, and comparing the current values with previously stored values to determine if any modifications have occurred. If a change is identified, the system updates the relevant data stores or notifies dependent services to maintain synchronization. This approach ensures that all components of the distributed system have access to the most recent transaction data, improving reliability and reducing discrepancies in financial or transactional workflows. The method is particularly useful in environments where transaction objects are frequently updated, such as banking, e-commerce, or supply chain management systems.
3. The method of claim 1 , further comprising: determining a number of times that the transaction object has undergone processing by the first microservice; and in response to determining that the number of times that the transaction object has undergone processing by the first microservice exceeds a threshold value, rejecting the transaction object as having failed processing associated with the first microservice.
This invention relates to transaction processing in microservice architectures, specifically addressing the problem of detecting and handling processing failures in distributed systems. In a microservice environment, transaction objects are passed between multiple microservices for sequential processing. The invention provides a method to monitor and control the processing of these transaction objects to prevent infinite loops or excessive processing attempts. The method involves tracking the number of times a transaction object is processed by a specific microservice. If the transaction object is processed by the same microservice more than a predefined threshold number of times, the system identifies this as a failure condition. In response, the transaction object is rejected, preventing further unnecessary processing attempts. This ensures system stability by avoiding resource exhaustion and infinite loops caused by repeated processing failures. The method also includes generating a notification or alert when a transaction object is rejected, allowing system administrators to investigate the root cause of the failure. The threshold value can be dynamically adjusted based on system performance metrics or historical data to optimize processing efficiency. This approach enhances reliability in microservice architectures by providing a mechanism to detect and mitigate processing failures early.
4. The method of claim 3 , further comprising: flagging the transaction object for further review based on rejecting the transaction; and holding the transaction object in the first workflow stage pending the further review, wherein updating the current workflow stage of the transaction object to a second workflow stage is based on determining that the further review is completed.
This invention relates to transaction processing systems, specifically methods for handling and reviewing transactions within a multi-stage workflow. The problem addressed is the need to efficiently manage transactions that require additional scrutiny, ensuring they are properly flagged, reviewed, and processed without disrupting the workflow. The method involves a transaction processing system that monitors transactions as they progress through predefined workflow stages. When a transaction is rejected, the system automatically flags it for further review and holds it in the current workflow stage. This prevents the transaction from advancing to the next stage until the review is complete. Once the review is finished, the system updates the transaction's status, allowing it to proceed to the subsequent workflow stage. The system ensures that only transactions meeting certain criteria are flagged, reducing unnecessary delays while maintaining compliance and accuracy. The workflow stages may include initial processing, validation, approval, or finalization, depending on the system's configuration. The method ensures that rejected transactions are not lost or overlooked, providing a structured approach to review and resolution. This improves efficiency by automating the flagging and holding process, reducing manual intervention and potential errors. The system may also log review details for auditing and reporting purposes.
5. The method of claim 4 , wherein flagging the transaction object for further review comprises flagging the transaction object for manual review by a user.
This invention relates to fraud detection in financial transactions, specifically a method for identifying and flagging suspicious transactions for manual review. The system monitors transaction data in real-time, analyzing patterns, anomalies, and risk indicators to detect potentially fraudulent activity. When a transaction is flagged as suspicious, it is automatically marked for further review by a human analyst. The method ensures that high-risk transactions are not processed without human oversight, reducing fraud losses while maintaining operational efficiency. The system may use machine learning models, rule-based checks, or a combination of both to assess transaction risk. Once flagged, the transaction is routed to a user interface where an analyst can verify its legitimacy before approval or rejection. This approach balances automation with human judgment, improving fraud detection accuracy and response time. The invention is particularly useful in banking, payment processing, and e-commerce, where fraud prevention is critical. By integrating automated detection with manual review, the system minimizes false positives and ensures compliance with regulatory requirements. The method can be applied to various transaction types, including credit card payments, wire transfers, and online purchases. The system may also log flagged transactions for auditing and continuous model improvement.
6. The method of claim 4 , wherein flagging the transaction object for further review comprises causing the transaction object to be processed by a second microservice, wherein updating the current workflow stage of the transaction object to the second workflow stage is based on determining that processing by the second microservice is completed.
This invention relates to transaction processing systems, specifically methods for flagging and reviewing transaction objects within a microservices architecture. The problem addressed is the need for efficient and automated handling of transactions that require additional scrutiny, ensuring compliance, fraud detection, or other review processes without disrupting the primary transaction flow. The method involves processing a transaction object through a first microservice, which identifies the need for further review. Upon detection, the transaction object is flagged and routed to a second microservice specialized in review tasks. The second microservice performs the necessary analysis, such as fraud detection, compliance checks, or risk assessment. Once processing by the second microservice is complete, the transaction object's workflow stage is updated to reflect the review status. This ensures that the transaction progresses only after the review is finalized, maintaining system integrity and regulatory compliance. The system dynamically manages transaction workflows by integrating multiple microservices, each handling specific stages of processing. The second microservice may include specialized algorithms or external data sources to assess transaction validity. The method ensures that transactions are only advanced to subsequent stages after all required reviews are completed, reducing errors and improving auditability. This approach enhances scalability and modularity in transaction processing systems.
7. The method of claim 1 , wherein the snapshot microservice records second snapshot data corresponding to the transaction object from prior to causing the first microservice to repeat processing of the transaction object, wherein the second snapshot data is maintained despite the repeat processing of the transaction object.
This invention relates to transaction processing in microservice architectures, specifically addressing the challenge of maintaining data consistency when a transaction object must be reprocessed by a microservice. In distributed systems, transaction objects may require reprocessing due to failures, retries, or state changes, but this can lead to data inconsistencies if intermediate states are lost. The invention provides a solution by using a snapshot microservice to capture and preserve snapshot data of the transaction object before reprocessing occurs. The snapshot microservice records second snapshot data corresponding to the transaction object prior to initiating the reprocessing by the first microservice. This second snapshot data is maintained even if the transaction object undergoes repeat processing, ensuring that the original state is preserved for reference or rollback purposes. The snapshot microservice operates independently, allowing the first microservice to proceed with reprocessing without overwriting or losing the pre-reprocessing state. This approach enhances data integrity and reliability in microservice environments by providing a mechanism to track and retain transaction states before modifications or retries. The solution is particularly useful in systems where transactions involve multiple steps or dependencies, as it ensures that intermediate states are not lost during reprocessing.
8. The method of claim 1 , further comprising: determining, by the snapshot microservice and via the streaming data platform, that at least one value associated with the transaction metadata has changed; retrieving, by the snapshot microservice and from the streaming data platform, the transaction object based on determining that the at least one value has changed; and storing, by the snapshot microservice, data corresponding to the changed at least one value associated with the transaction metadata.
This invention relates to a system for monitoring and updating transaction metadata in a streaming data platform. The problem addressed is the need to efficiently track changes in transaction metadata and ensure data consistency across distributed systems. The solution involves a snapshot microservice that monitors transaction metadata for changes and updates stored data accordingly. The system includes a streaming data platform that processes transaction objects, each containing metadata describing the transaction. The snapshot microservice continuously monitors the streaming data platform for changes in transaction metadata values. When a change is detected, the microservice retrieves the corresponding transaction object from the streaming data platform. The microservice then stores the updated metadata values, ensuring that the latest transaction state is preserved. The method further includes generating a snapshot of the transaction object, which captures the current state of the transaction metadata. This snapshot is stored in a persistent storage system, allowing for historical tracking and retrieval of transaction data. The snapshot microservice may also validate the integrity of the transaction metadata before storing it, ensuring data accuracy. The invention improves data consistency and reliability in distributed systems by automating the detection and storage of transaction metadata changes. This reduces manual intervention and minimizes errors in transaction tracking. The system is particularly useful in financial, e-commerce, and other transaction-heavy applications where real-time data accuracy is critical.
9. The method of claim 1 , wherein the next workflow stage corresponds to the first workflow stage associated with the first microservice.
This invention relates to workflow management in microservice architectures, addressing the challenge of efficiently routing tasks between distributed microservices. The system automates the transition of workflow stages, ensuring seamless execution across multiple microservices without manual intervention. The method involves identifying a current workflow stage, determining the next stage based on predefined rules, and dynamically routing the workflow to the appropriate microservice. The invention ensures continuity by linking subsequent stages to the initial microservice, maintaining consistency in task processing. This approach optimizes resource utilization, reduces latency, and enhances scalability in distributed systems. The system may also include error handling mechanisms to manage failures during stage transitions, ensuring robustness. The method is particularly useful in cloud-native applications where microservices must collaborate to complete complex workflows. By automating stage transitions, the invention minimizes operational overhead and improves system reliability. The solution is adaptable to various industries, including finance, healthcare, and e-commerce, where workflow automation is critical for efficiency.
10. The method of claim 1 , wherein the initialization stage corresponds to the first workflow stage.
A system and method for workflow management involves initializing a workflow process by aligning an initialization stage with the first workflow stage. The method includes defining a workflow comprising multiple stages, where each stage represents a distinct phase of a process. The initialization stage is configured to prepare the workflow for execution by setting initial parameters, validating inputs, or allocating resources. By aligning the initialization stage with the first workflow stage, the system ensures that preparatory steps are seamlessly integrated into the workflow, reducing delays and improving efficiency. The method may further include transitioning between stages based on predefined conditions, such as completion of tasks or validation checks. The system may also monitor workflow progress, detect errors, and trigger corrective actions. This approach streamlines workflow execution by eliminating separate initialization steps, ensuring a continuous and optimized process flow. The method is applicable in various domains, including manufacturing, software development, and business process automation, where efficient workflow management is critical.
11. The method of claim 1 , wherein the snapshot microservice generates a transaction history for the transaction object.
A system and method for managing transaction data in a distributed computing environment addresses the challenge of efficiently tracking and retrieving transaction histories in decentralized systems. The invention involves a snapshot microservice that captures and processes transaction data to generate a comprehensive transaction history for each transaction object. This history includes all relevant events, modifications, and interactions associated with the transaction, ensuring data integrity and traceability. The microservice operates independently, allowing it to function within a modular architecture where different components handle specific tasks. The transaction history is structured to facilitate quick retrieval and analysis, supporting auditing, debugging, and compliance requirements. By generating a detailed transaction history, the system enables users to reconstruct the lifecycle of a transaction, identify discrepancies, and verify data consistency across distributed nodes. The method ensures that transaction data remains accurate and tamper-proof, enhancing reliability in decentralized applications. The snapshot microservice can be integrated into existing systems or deployed as part of a new architecture, providing flexibility in implementation. This approach improves transparency and accountability in transaction processing, making it suitable for financial systems, supply chain management, and other domains requiring robust transaction tracking.
12. The method of claim 1 , wherein the snapshot microservice generates a transaction history for each transaction object added to the streaming data platform.
A system and method for managing transaction data in a streaming data platform involves generating and maintaining a transaction history for each transaction object processed by the platform. The system includes a snapshot microservice that captures and records transaction data as it flows through the platform, ensuring that a complete and accurate history of each transaction is preserved. This history includes details such as the transaction's origin, processing steps, and any modifications made during its lifecycle. The snapshot microservice operates independently, allowing it to function without disrupting the real-time data streaming process. By maintaining this transaction history, the system enables auditing, debugging, and compliance tracking, ensuring that all transaction data can be traced back to its source and verified for accuracy. The method also includes mechanisms for storing and retrieving the transaction history, making it accessible for analysis and reporting. This approach improves data integrity and transparency in streaming data environments, addressing challenges related to tracking and verifying transaction data in high-velocity systems.
13. The method of claim 1 , wherein the snapshot microservice stores snapshot data in an on-disk database.
A system and method for managing snapshot data in a distributed computing environment addresses the challenge of efficiently capturing and storing state information from multiple services or components. The system includes a snapshot microservice that periodically or on-demand captures snapshots of system state, which may include configuration data, runtime metrics, or other relevant information. These snapshots are then stored in a centralized on-disk database, ensuring persistence and enabling recovery or analysis. The on-disk database provides durable storage, allowing snapshots to be retrieved even after system restarts or failures. The snapshot microservice may also include features such as compression, encryption, or metadata tagging to optimize storage efficiency and security. By storing snapshots in a structured database, the system enables querying, filtering, and historical analysis of system states, supporting debugging, auditing, and performance monitoring. The approach ensures that critical state information is preserved and accessible, improving system reliability and operational insights.
14. A transaction exchange platform system comprising: a streaming data platform; a plurality of microservices, wherein each microservice of the plurality of microservices is configured to watch for transactions on the streaming data platform in a corresponding workflow stage based on a plurality of workflows corresponding to a plurality of transaction types; at least one processor; and memory storing instructions that, when executed by the at least one processor, cause the transaction exchange platform system to: receive a transaction object corresponding to a payment transaction, wherein the transaction object comprises transaction details, addenda data, and transaction metadata, and wherein the transaction metadata comprises: an indication of a workflow corresponding to a transaction type of the transaction object, wherein the workflow corresponding to the transaction type comprises a plurality of processing steps required to validate a given transaction of the transaction type; and a current workflow stage of the transaction object; add the transaction object to a streaming data platform, wherein adding the transaction object to the streaming data platform comprises setting the current workflow stage of the transaction object to an initialization stage; poll, by a snapshot microservice, the streaming data platform to retrieve transactions matching the initialization stage, wherein the initialization stage is associated with the snapshot microservice; retrieve, by the snapshot microservice and from the streaming data platform, the transaction object based on the current workflow stage matching the initialization stage; store, by the snapshot microservice, snapshot data corresponding to the transaction object, update the current workflow stage of the transaction object to a next workflow stage based on completing storing, by the snapshot microservice, the snapshot data corresponding to the transaction object; retrieve, by a first microservice and from the streaming data platform, the transaction object based on the current workflow stage matching a first workflow stage, wherein the first workflow stage is associated with the first microservice based on the workflow corresponding to the transaction type; process, by the first microservice, the transaction object to modify the addenda data; determine, by the snapshot microservice and via the streaming data platform, that at least one value associated with the addenda data of the transaction object has changed after the transaction object has left the initialization stage; store, by the snapshot microservice, snapshot data corresponding to the changed at least one value associated with the addenda data; determine that the processing, by the first microservice, of the transaction object did not complete successfully; cause the first microservice to repeat processing of the transaction object based on the snapshot data corresponding to the transaction object from prior to the start of the processing by the first microservice, wherein the instructions cause the transaction data platform system to repeat processing of the transaction object by causing the transaction exchange platform system to: regenerate, by the snapshot microservice, the transaction object based on the snapshot data corresponding to the transaction object from prior to the start of the processing by the first microservice; and return the regenerated transaction object to the streaming data platform, wherein a current workflow stage of the regenerated transaction object is set to the first workflow stage; determine that the current workflow stage of the transaction object indicates that the transaction object has completed processing corresponding to the workflow; and remove the transaction object from the streaming data platform and outputting the transaction object and an indication that the transaction object has completed the processing corresponding to the workflow to a downstream system.
A transaction exchange platform system processes payment transactions through a series of workflow stages using a streaming data platform and microservices. The system handles transactions of different types, each with a predefined workflow comprising multiple processing steps. When a transaction object is received, it includes transaction details, addenda data, and metadata specifying its workflow and current stage. The system adds the transaction to the streaming platform, initially setting its stage to initialization. A snapshot microservice polls the platform, retrieves transactions in the initialization stage, stores snapshot data, and advances the transaction to the next stage. Subsequent microservices process the transaction, modifying addenda data as needed. If a microservice fails, the snapshot microservice detects changes in the addenda data, stores a snapshot, and regenerates the transaction from the pre-processing state, restarting the failed stage. Once all workflow stages are completed, the system removes the transaction from the streaming platform and outputs it to a downstream system. This approach ensures transaction integrity and recoverability through snapshot-based rollback mechanisms.
15. The transaction exchange platform system of claim 14 , wherein the snapshot microservice generates a transaction history for each transaction object added to the streaming data platform.
The transaction exchange platform system is designed to facilitate secure and efficient financial transactions by leveraging a distributed streaming data platform. The system addresses challenges in transaction processing, such as latency, scalability, and data consistency, by using a microservices architecture to handle different aspects of transaction management. A key component is the snapshot microservice, which generates a transaction history for each transaction object added to the streaming data platform. This ensures that all transaction data is recorded and can be retrieved for auditing, analysis, or dispute resolution. The snapshot microservice captures transaction details, including timestamps, participant identities, and transaction statuses, and stores them in a structured format. This allows for real-time monitoring and historical tracking of transactions, improving transparency and reliability in financial exchanges. The system also includes other microservices that handle transaction validation, routing, and settlement, ensuring that transactions are processed securely and efficiently. By integrating these microservices with the streaming data platform, the system provides a scalable and resilient infrastructure for high-volume transaction processing. The snapshot microservice's ability to generate transaction histories enhances accountability and compliance with regulatory requirements.
16. The transaction exchange platform system of claim 14 , wherein the instructions further cause the transaction exchange platform system to: determine a number of times that the transaction object has undergone processing by the first microservice; and in response to determining that the number of times that the transaction object has undergone processing by the first microservice exceeds a threshold value, reject the transaction object as having failed processing associated with the first microservice.
The transaction exchange platform system operates in the domain of distributed transaction processing, addressing the challenge of ensuring reliable execution of transactions across multiple microservices. The system monitors transaction objects as they are processed by interconnected microservices, tracking their progress to detect and handle failures. Specifically, the system counts how many times a transaction object is processed by a particular microservice. If this count exceeds a predefined threshold, the system concludes that the transaction has failed due to repeated processing attempts by the microservice and rejects the transaction object. This mechanism prevents infinite loops or excessive retries that could degrade system performance or lead to inconsistent states. The system may include a transaction exchange platform that manages the flow of transaction objects between microservices, ensuring that each transaction is processed according to defined rules and constraints. The threshold value can be dynamically adjusted based on system conditions or configured to specific requirements, allowing flexibility in handling different types of transactions and microservice behaviors. This approach enhances system reliability by automatically identifying and rejecting transactions that cannot be successfully processed within acceptable limits.
17. One or more non-transitory computer readable media storing instructions that, when executed by at least one processor, cause a transaction exchange platform to perform steps comprising: receiving a transaction object comprising transaction details, addenda data, and transaction metadata, wherein the transaction metadata comprises: an indication of a workflow corresponding to a transaction type of the transaction object, wherein the workflow corresponding to the transaction type comprises a plurality of processing steps required to validate a given transaction of the transaction type; and a current workflow stage of the transaction object; adding the transaction object to a streaming data platform, wherein adding the transaction object to the streaming data platform comprises setting the current workflow stage of the transaction object to an initialization stage; polling, by a snapshot microservice, the streaming data platform to retrieve transactions matching the initialization stage, wherein the initialization stage is associated with the snapshot microservice; retrieving, by the snapshot microservice and from the streaming data platform, the transaction object based on the current workflow stage matching the initialization stage; and storing, by the snapshot microservice, snapshot data corresponding to the transaction object, updating the current workflow stage of the transaction object to a next workflow stage based on completing storing, by the snapshot microservice, the snapshot data corresponding to the transaction object; retrieving, by a first microservice and from the streaming data platform, the transaction object based on the current workflow stage matching a first workflow stage, wherein the first workflow stage is associated with the first microservice based on the workflow corresponding to the transaction type; processing, by the first microservice, the transaction object to modify the addenda data; determining, by the snapshot microservice and via the streaming data platform, that at least one value associated with the addenda data of the transaction object has changed after the transaction object has left the initialization stage; storing, by the snapshot microservice, snapshot data corresponding to the changed at least one value associated with the addenda data; determining that the processing, by the first microservice, of the transaction object did not complete successfully; and causing the first microservice to repeat processing of the transaction object based on the snapshot data corresponding to the transaction object from prior to the start of the processing by the first microservice, wherein causing the first microservice to repeat processing of the transaction object comprises: regenerating, by the snapshot microservice, the transaction object based on the snapshot data corresponding to the transaction object from prior to the start of the processing by the first microservice; and returning the regenerated transaction object to the streaming data platform, wherein a current workflow stage of the regenerated transaction object is set to the first workflow stage determining that the current workflow stage of the transaction object indicates that the transaction object has completed processing corresponding to the workflow; and removing the transaction object from the streaming data platform and outputting the transaction object and an indication that the transaction object has completed the processing corresponding to the workflow to a downstream system.
This invention relates to a transaction exchange platform that processes transactions through a defined workflow using a streaming data platform and microservices. The system addresses the challenge of managing complex transaction processing with multiple validation steps, ensuring data integrity and recovery in case of failures. The platform receives a transaction object containing transaction details, addenda data, and metadata, including a workflow definition and current stage. The workflow specifies processing steps required for validation, with each stage assigned to a specific microservice. Initially, the transaction is set to an initialization stage and added to the streaming data platform. A snapshot microservice polls the platform, retrieves transactions in the initialization stage, and stores snapshot data before advancing the transaction to the next stage. Subsequent microservices process the transaction, modifying addenda data as needed. If a microservice fails, the snapshot microservice detects changes in the addenda data, stores a new snapshot, and regenerates the transaction from the pre-processing snapshot to retry the failed step. Once all stages are completed, the transaction is removed from the platform and sent to a downstream system. This approach ensures robust transaction processing with built-in recovery mechanisms.
18. The transaction exchange platform system of claim 16 , wherein the instructions further cause the transaction exchange platform system to: flag the transaction object for further review based on rejecting the transaction; and hold the transaction object in the first workflow stage pending the further review, wherein updating the current workflow stage of the transaction object to a second workflow stage is based on determining that the further review is completed.
The transaction exchange platform system is designed to facilitate and manage transactions between parties, particularly in environments where automated processing may not be sufficient to handle all cases. A key challenge in such systems is ensuring that transactions are properly reviewed and validated, especially when automated processes flag potential issues. The system addresses this by implementing a workflow-based approach to transaction processing, where transactions can be flagged for further review if they are rejected during automated processing. When a transaction is rejected, the system flags the transaction object for manual or additional review and holds it in the initial workflow stage until the review is completed. Only after the review is finished does the system advance the transaction object to the next workflow stage, ensuring that all necessary checks are performed before proceeding. This mechanism helps maintain transaction integrity and compliance while allowing for flexible handling of exceptions. The system may include various workflow stages, each representing a different phase of transaction processing, and the transition between stages is controlled based on the outcome of reviews or validations. This approach improves efficiency by automating routine transactions while ensuring that flagged transactions receive the necessary attention.
19. The transaction exchange platform system of claim 18 , wherein the instructions cause the transaction exchange platform system to flag the transaction object for further review by causing the transaction exchange platform to flag the transaction object for manual review by a user.
A transaction exchange platform system is designed to facilitate secure and efficient transactions between parties. The system processes transaction objects, which represent financial or data exchanges, and includes mechanisms to detect and handle potentially problematic transactions. One key feature involves flagging transaction objects for further review when certain conditions are met. When a transaction object is flagged, the system triggers a manual review process, where a user—such as an administrator or compliance officer—examines the transaction to ensure its validity, detect fraud, or verify compliance with regulations. This manual review step adds an additional layer of oversight, reducing the risk of errors or malicious activity. The system may flag transactions based on predefined criteria, such as unusual patterns, high-value amounts, or discrepancies in transaction details. By integrating automated detection with human review, the platform enhances security and reliability in transaction processing. This approach is particularly useful in financial services, e-commerce, or any domain where transaction integrity is critical. The manual review process ensures that suspicious or high-risk transactions are thoroughly evaluated before being finalized, improving trust and compliance within the system.
20. The transaction exchange platform system of claim 18 , wherein the instructions cause the transaction exchange platform system to flag the transaction object for further review by causing the transaction exchange platform to cause the transaction object to be processed by a second microservice, wherein updating the current workflow stage of the transaction object to the second workflow stage is based on determining that processing by the second microservice is completed.
A transaction exchange platform system is designed to manage and process transaction objects through a series of workflow stages. The system includes a transaction exchange platform that processes transaction objects using microservices, where each microservice performs specific tasks on the transaction object. The system tracks the current workflow stage of each transaction object and updates it as the object progresses through the workflow. In one implementation, the system flags a transaction object for further review by routing it to a second microservice for additional processing. The transaction object remains in its current workflow stage until the second microservice completes its processing. Once processing is finished, the system updates the transaction object's workflow stage to the next stage, indicating that the review or additional processing has been completed. This ensures that transactions are only advanced to the next stage after all necessary checks or actions are performed, improving accuracy and compliance in transaction processing. The system may include multiple microservices, each handling different aspects of transaction validation, review, or execution, and the workflow stages are dynamically updated based on the completion of these microservices' tasks. This modular approach allows for flexible and scalable transaction processing.
Unknown
September 29, 2020
Browse 5M+ US patents with plain-English claim translations and AI-generated analysis.