Technical system for the audit-proof, tamper-resistant release of event-dependent actions between independent systems using a multi-stage, four-block-structured verification chain and a deterministic state machine

Abstract

System for the audit-proof, tamper-resistant release of an event-dependent action between independent systems, including: • a consent module (CM) set up to capture identity-based consent from a data subject with timestamp (t), source, wording version identifier and checksum as a consent event (E_C) and to log the consent event (E_C) in an append-only event store (Event Store, ES), • Communication means set up to obtain a separate second confirmation of consent via a communication channel different from the initial recording as an out-of-band event (E_oob) and to cryptographically bind the out-of-band event (E_oob) to the checksum generated in the consent event (E_C), • a generation device set up to generate a unique case identifier (case_id) to which all associated events are bound, wherein the generation device is preferably designed such that pseudonymous identifiers (PID_U, PID_ext) are derived from a common set of features in different trust domains using organization-specific salts (S_U, S_ext) and hash functions, • the Append-Only Event Store (ES), set up to store all relevant events including consent events (E_C), out-of-band events (E_oob), status changes, negative events (E_neg), and success signals from participating systems, with monotonically increasing, sequential numbering, idempotence keys, and replay protection to detect gaps, duplicates, and backdating, • at least one adapter layer for success signals (CA), configured to receive at least two cryptographically signed success signals from independent trust domains, to check the signatures, origin and time consistency of the success signals, and to link the success signals with the case identifier (case_id, PID_U, PID_ext) taking into account a permissible time window (Δt), the consistency of the communication channel and optional negative lists, • a revision ledger module (AL) configured to store selected checksums, references to sequential numbers of the event store (ES) and timestamps of the logged events, in particular E_C, E_oob, E_success and E_neg, in a revision ledger physically or logically separate from the event store (ES), wherein the entries of the revision ledger are linked by means of a hash chain, where each entry comprises a hash value derived from at least the immediately preceding entry (prev_hash), • an anchoring service (AS) set up to periodically generate Merkle roots over defined sections of the revision ledger and to transmit the Merkle roots to an external timestamp instance (TSA), whereby the signed timestamps generated by the timestamp instance are stored together with the Merkle roots as anchor events (E_anchor, ledger_anchor) in the revision ledger, • a timer (TI) with negative monitor, set up to enforce a technical waiting period between a confirmed success event (E_success) and a possible release of the event-dependent action, as well as to monitor for the occurrence of negative events (E_neg), in particular revocation, cancellation, chargeback and integrity errors in the event log (ES) or revision ledger (AL), • a Settlement Verifier (SV) set up to check a verified target event (E_settlement) that includes a signature, a timestamp and a reference to the operation ID, and to match the target event (E_settlement) with the operation ID (case_id, PID_U, PID_ext) and the evidence chain from the event store (ES) and revision ledger (AL) including the external anchor (ledger_anchor), • a Release Engine (RE), configured to trigger the event-dependent action idempotently only when a Process Service (PS) based on a state machine has determined that the consent and second confirmation level, the event log with multi-source confirmation, the revision ledger with external time anchor and the waiting period with negative monitoring have been fulfilled without objection, and the verified target event (E_settlement) has been confirmed, where the Process Service (PS) manages the system in states including CREATED, CONSENT_OK, OOB_OK, CASE_ACTIVE, EVENTS_OK, SUCCESS CONFIRMED, LEDGER_ANCHORED, WAITING_PERIOD, PAYABLE and PAID, as well as in lock, block and quarantine states (QUARANTINED, BLOCKED, WITHDRAWN, DENIED), and allows the release of the event-dependent action exclusively from a releaseable state (PAYABLE) towards PAID.

Description

Technical field

[0001] The invention relates to the field of computer-implemented, distributed information systems.

[0002] It particularly concerns: • Computer-implemented technical controls for enabling and disabling event-dependent actions between independent systems or trust domains, • Computer-aided gatekeeper systems for audit-proof processing of events with tamper-resistant documentation and • Technical mechanisms for data-efficient cooperation (pseudonymization, tokens, role and attribute control) in regulated environments, for example in insurance, finance or energy applications, but not limited to these. State of the art

[0003] Typical problems include: • lack of properly documented and verifiable consent management in accordance with the General Data Protection Regulation (GDPR), • unclear definition of a minimum required data set (data economy), • Media breaks (paper forms, email, Excel lists, manual post-processing), • Insufficient technical correlation of events such as notification, consultation, closing, payment (Who triggered which closing and when?), • Legally questionable procedures regarding remuneration for intermediary or cooperating parties, particularly with regard to regulatory requirements, legal restrictions on the passing on of remuneration to customers and licensing requirements, • Lack of audit security and clarity regarding the burden of proof in disputes concerning identity, timing, revocation, cancellation or double payment.

[0004] Well-known CRM systems, platform-based systems for exchanging sales contacts, or simple logging solutions usually address these points organizationally: • Consent is documented in form fields, • Events are logged chronologically, • Evaluations are carried out via reports or export-specific tables.

[0005] These systems offer subsequent evaluation options, but not a technically enforced, multi-stage approval of a subsequent action.

[0006] In particular: • Logs can be subsequently altered or kept incompletely, • External time anchors (e.g., through an independent timestamp instance) are rarely integrated, • Multi-source confirmations (e.g., from the sales system and payment system) are not used as a hard technical condition for approval, • Cancellations, revocations, or integrity errors usually do not automatically prevent the execution of an action that has already been initiated, but are merely handled organizationally.

[0007] Thus, a system is lacking that not only logs the release of an event-dependent action, but also technically enforces that a defined, multi-stage test chain has been successfully and consistently completed across multiple blocks. Object of the invention

[0008] The object of the invention is to provide a complete technical system that: • digitally captures, versiones, and cryptographically binds identity-based consent, • Processes clearly identified and optionally pseudonymized, • Relevant events are logged only as an addendum, completely and with integrity controls, • Technical success events from multiple technical sources correlate, • Stores audit-relevant data in a revision ledger separate from the production data storage, with a hash chain and external time anchor, • a technical waiting period and negative events (cancellation, cancellation, chargeback, integrity errors) are taken into account and • only releases an event-dependent action if all conditions of the verification chain are met and verifiable in a machine-readable manner - while simultaneously minimizing data processing, pseudonymization and role- or attribute-based access restriction.

[0009] At the same time, the system should be designed so that it can be used not only for payments or remuneration, but also for other actions requiring approval (e.g., enabling technical services, API access, configuration changes, write access to security-critical storage areas).

[0010] Furthermore, the invention is designed such that the same multi-stage test chain and the same state machine can be reused in different technical application scenarios without adapting the core logic. Summary of the invention

[0011] The invention provides a computer-implemented gatekeeper system that divides a multi-stage verification chain into four technical blocks. An event-dependent action (e.g., payment, service activation, configuration change) is only released if all four blocks have been completed fully, consistently, and without negative events. • Block 1 captures identity-based consent with timestamp, source, wording version and checksum, obtains a separate out-of-band confirmation via an independent communication channel and links both confirmations with a unique process identifier, which is optionally pseudonymized and derived from a set of characteristics and an organization-specific salt. • Block 2 logs all relevant events (consents, confirmations, status changes, negative events) in an append-only event log with sequential numbering, idempotence mechanisms, and replay protection, and confirms a business success via at least two cryptographically signed success signals from independent trust domains. Time windows (Δt), channel consistency, optional geofactors, and blacklists are taken into account. In preferred embodiments, these success signals originate from an external sales or cooperation domain (C_ext) and an external provider or product supplier domain (EXT_PROVIDER), thus providing double confirmation of a transaction across domains. Block 3 stores selected checksums and metadata of the events in a revision ledger separate from the production data storage, links these entries using a hash chain, and periodically anchors Merkle roots to an external timestamp instance as an external time anchor. If this instance fails, a blocking state is set, preventing any releases. Block 4 enforces a technical waiting period between confirmation of success and the potential release of an action. During this time, it monitors for negative events (revocation, cancellation, chargeback, integrity errors) and verifies a verified target event before releasing the action. If a negative event occurs, the process is placed in a blocked or quarantine state. In preferred embodiments, the state machine additionally manages states representing expected billing processes, the receipt of a billing message, and missed or implausible billings, without the gatekeeper system itself executing payment flows.

[0012] A deterministic state machine represents these four blocks as a technical gatekeeper structure. It holds processes in intermediate or error states (e.g., QUARANTINED, BLOCKED, WITHDRAWN, DENIED) until all conditions are met. The actual action (e.g., payment, service activation, write access) cannot be triggered if the verification chain is not completed without contradictions. In embodiments with billing monitoring, the state machine also indicates whether a technically expected, received, or outstanding billing occurs at a doubly confirmed transaction.

[0013] The technical effect results from the interaction of all four blocks: Even if individual mechanisms such as hash chains, external timestamps, or two-factor authentication are known, it is only their tight coupling within the state machine that ensures a subsequent action can only be executed if all upstream checks have been successful. Additionally, preferred implementations ensure across domains that not only the completion of a process, but also its settlement and payment status, is technically traceable and auditable across the participating trust domains. This distinguishes the system from known solutions that merely document checks and settlements but do not enforce them as a hard technical release condition or as a domain-spanning control instance. Brief description of the drawings Fig. 1 - System overview, trust domains and neutral gatekeeper instance Fig. Figure 1 shows a system overview with several independent trust domains: a domain with a data subject (K) and an upstream data collection component (V), a domain of a regulated primary company (U), an external sales or cooperation domain (C_ext), and a domain of an external provider or product supplier (EXT_PROVIDER). The domains are each identified by areas outlined with a dashed line. At the center is a gatekeeper system (GK), which is technically separate from the aforementioned trust domains and does not itself constitute a trust domain. The gatekeeper system (GK) includes several functional modules: a Process Service (PS) for process control and state management, an Event Store (ES) as an append-only event storage system, a Revision Ledger (AL) for the audit-proof logging of selected audit data, and a component (TSA) that represents a connection to an external timestamp instance. Schematically represented connections exist between the domains (K / V, U, C_ext, EXT_PROVIDER) and the gatekeeper system (GK), through which event-related data, checksums, acknowledgments, and status signals are exchanged. The connections shown in Fig. The overview shown in Figure 1 illustrates that the Gatekeeper (GK) is designed as a neutral, cross-domain instance that correlates the information supplied by the different trust domains and only technically allows the release of event-dependent actions when the multi-stage verification chain, divided into four blocks, is fully and consistently fulfilled. Fig. 2 - Blocks 1 and 2: Consent, out-of-band confirmation, pseudonymous transaction identifiers and multi-source confirmation Fig. Figure 2 shows an embodiment of the first two verification stages within the Gatekeeper System (GK). At the center is an extended Event Store (ES), which serves as an append-only event repository for recording consent, confirmation, and success events. Above the Event Store (ES) are an out-of-band confirmation adapter (CA_oob), a consent module (CM), a pseudonymization service (PSE), and a domain-specific confirmation adapter (CA_U). Below the Event Store (ES) are a negative list module (NL), a multi-source success event (E_success), and another domain-specific confirmation adapter (CA_ext). In one embodiment, the consent module (CM) is addressed via a consent form provided by the Gatekeeper, which is integrated into the user interfaces of the participating trust domains and controls the selection of an approved consent template and the respective permitted contact channels.

[0014] The Consent Module (CM) captures digital consent events (E_C) with a timestamp, wording version identifier, and checksum, and transfers these to the Event Store (ES). An out-of-band confirmation (E_oob) is obtained via a separate communication channel using the Out-of-Band Confirmation Adapter (CA_oob) and linked to the checksum of the consent event (E_C). The Pseudonymization Service (PSE) generates pseudonymous case identifiers (case_id) and organization-specific identifiers (PID_U, PID_ext) from a domain-specific set of attributes. These are also stored in the Event Store (ES) and used to correlate the events.

[0015] The domain-specific confirmation adapters (CA_U, CA_ext) are configured to transmit signed success signals (for example, success_a from domain U and success_b from domain C_ext) to the event store (ES). The negative list module (NL) can perform event-related checks against blocklists or negative lists and enter corresponding negative events (E_neg) into the event store (ES). From the entries in the event store (ES), the gatekeeper (GK) generates a multi-source success event (E_success) by taking into account signatures, time windows (Δt), consistency of communication channels, and negative lists. E_success thus forms an aggregated proof of success across multiple independent trust domains and completes the verification steps of blocks 1 and 2. Fig. 3 - Block 3: Revision ledger, hash chain, Merkle root and external time anchor

[0016] Fig. Figure 3 shows an embodiment of a revision ledger (AL) separate from the event store (ES) within the gatekeeper system (GK), as well as a subsequent Merkle and timestamp structure. The event store (ES) is located on the left side of the gatekeeper (GK). A revision ledger (AL) is shown in the center, comprising several append-only ledger entries, exemplified in the figure by entries (AL_1, AL_2) and a special anchor entry (ledger_anchor).

[0017] Each ledger entry contains a digital checksum of the respective data and a reference to the previous ledger entry, for example, via a `prev_hash` field. The diagram shows arrows between AL_1, AL_2, and the anchor entry (`ledger_anchor`), indicating the formation of a hash chain. Incoming checksums and event references from the event log (ES) are stored in the revision ledger (AL) as ledger entries (AL_1, AL_2, ...).

[0018] To the right of the revision ledger (AL) is an aggregation stage in the form of a Merkle root (MR). A Merkle root (MR) is calculated from a group of ledger entries in the revision ledger (AL), serving as a compressed integrity representation of the affected entries. The Merkle root (MR) is passed to an external timestamp instance (TSA), which generates a signed external timestamp. The in Fig. The entry shown (ledger_anchor) represents a ledger entry in which such an external time anchor can be stored in the revision ledger (AL), so that the integrity and temporal classification of the logged evidence can later be verified using the combination of revision ledger (AL), Merkle root (MR) and external timestamp, and block 3 of the audit chain is completed. Fig. 4 - Block 4: Deterministic state machine and monitoring of negative events

[0019] Fig. Figure 4 shows a deterministic state machine of the gatekeeper (GC) with a sequence of main states and several special states. On the left side of the gatekeeper (GC), the main states CREATED, CONSENT_OK, OOB_OK, CASE_ACTIVE, EVENTS_OK, SUCCESS_CONFIRMED, LEDGER_ANCHORED, WAITING_PERIOD, PAYABLE, and PAID are arranged in a vertical chain. The states are represented by rectangles, between which arrows run, thus illustrating a linear transition from CREATED to PAID.

[0020] In the states OOB_OK and CASE_ACTIVE, out-of-band confirmation checks and other technical preconditions can fail, triggering transitions to negative special states such as DENIED (starting from OOB_OK) or BLOCKED (starting from CASE_ACTIVE). These special states are described in Fig. 4 shown to the right of the respective main states.

[0021] At the WAITING_PERIOD state, a timer module (TI) is located and linked to WAITING_PERIOD via a horizontal connection. The timer module (TI) monitors a technical waiting period in the WAITING_PERIOD state between LEDGER_ANCHORED and PAYABLE, as well as incoming negative events (E_neg) that may occur within this waiting period. The figure shows that the timer module (TI) can trigger state transitions to the special states QUARANTINED and WITHDRAWN by first transitioning from WAITING_PERIOD to TI, then from TI to QUARANTINED, and finally from QUARANTINED to WITHDRAWN. The transition from PAYABLE to PAID only occurs after the preceding checks of blocks 1 to 3 have been completed and no blocking negative events have been detected, possibly depending on a previously verified settlement event (E_settlement). Fig. 5 - Modular architecture and interfaces of the Gatekeeper system

[0022] Fig. Figure 5 shows an embodiment of the modular architecture of the Gatekeeper System (GK). Several functional modules are arranged within a Gatekeeper frame. At the center is a Process Service (PS), which serves as the state machine and orchestration core of the verification chain described in blocks 1 to 4. To its left is a Consent Module (CM), which captures consents and passes them to the Process Service (PS). To its right is an Access Control Service (ACS), which manages access rights and authorization tokens for calls to the Gatekeeper and is coupled to the Process Service (PS).

[0023] In a lower layer, a Pseudonymization Service (PSE), an Event Store (ES), and an Adapter Layer for Success Signals (CA) are arranged. The Pseudonymization Service (PSE) generates pseudonymous process identifiers and passes them to the Event Store (ES), which serves as an append-only event storage. The Adapter Layer (CA) receives cryptographically signed events and success signals from external systems and feeds them into the Event Store (ES).

[0024] Below this is a Revision Ledger (AL) that takes selected checksums and references from the Event Store (ES) and serves as a hash-linked revision record. Adjacent to the Revision Ledger (AL) is an Anchoring Service (AS) that calculates Merkle roots from the ledger entries and transmits them to an external timestamp instance. Below the Anchoring Service (AS) is a Timer Module (TI) that monitors wait times and negative events and sends corresponding signals to the other components.

[0025] At a lower level, a Settlement Verifier (SV) and a Release Engine (RE) are depicted. The Settlement Verifier (SV) checks verified target and settlement events against the evidence stored in the Event Store (ES) and the Revision Ledger (AL). The Release Engine (RE) is configured so that, after successful verification and a release-ready state, it can technically trigger the event-dependent action.

[0026] Outside the gatekeeper framework, the diagram illustrates a regulated primary company (U), an external sales or cooperation domain (C_ext), and an external vendor or product supplier domain (EXT_PROVIDER). The primary company (U) is connected to the gatekeeper via the consent module (CM), while the external domains (C_ext, EXT_PROVIDER) are connected via the adapter layer (CA). The diagram demonstrates that all events and signals from the participating trust domains are transferred via defined interfaces to the Event Store (ES) and Revision Ledger (AL) and correlated there with the states controlled by the Process Service (PS) before the Release Engine (RE) releases an event-driven action. Detailed description of the invention; Definitions of terms • Case ID: Unique identifier of a process; in preferred implementations, it can be derived as a pseudonymous identifier (PID) from a set of characteristics and an organization-specific salt using a hash function. • Trust domain: A technically or organizationally independent system with its own signature and timing logic (e.g., distribution system, billing system, payment provider). In the diagrams, dashed-bordered areas each represent a trust domain; the components depicted within the border technically belong to the same trust domain. The gatekeeper (GC) is designed as a central system between the trust domains and does not itself constitute a trust domain. • Revision ledger: Separate storage containing only checksums, hashes, timestamps and references to the process identifier, structured as a hash chain with an external time anchor. • Target event: Event whose occurrence serves as a prerequisite for the release of the action (e.g., confirmed payment run, activation of a service, activation of a configuration). System overview and domains of trust

[0027] The system includes at least: • a component for consent collection (Consent Module, CM), • a central state machine (Process Service, PS), • an append-only event store (ES), • an audit ledger with hash chain and external time anchor (audit ledger, AL), • at least two independent trust domains that provide signals of success, • a timer for wait period management and monitoring of negative events (TI) as well as • a Release Engine (RE) for the actual execution of the event-dependent action.

[0028] The trust domains involved can be physically separate systems or logically separate subsystems with their own keys, time sources, and integrity mechanisms. In preferred embodiments, the architecture includes, in particular, • an external sales or cooperation domain (C_ext) that provides technical events such as notifications, consultations and closing messages, and • an external provider or product supplier domain (EXT_PROVIDER) that provides the technical or contractual effectiveness status of a product or service.

[0029] The regulated primary company (U) can be separate from the external sales domain (C_ext) and the external provider or product supplier domain (EXT_PROVIDER) and uses the gatekeeper system as a neutral, cross-domain auditing authority. Enhanced monitoring of completion and settlement status

[0030] In a preferred embodiment, the gatekeeper system is additionally configured to technically monitor completion and settlement status across multiple trust domains without itself initiating or processing payment flows.

[0031] For this purpose, the gatekeeper initially receives corresponding success or completion messages for a process from at least two independent trust domains. In a preferred implementation, this includes • a message from the external sales or cooperation domain (C_ext) indicating a contract or transaction that has been successfully brokered from a sales perspective, and • a message from the external provider or product supplier domain (EXT_PROVIDER) that confirms or rejects the contract or service status from the perspective of the offering system.

[0032] Only if both messages can be assigned to an identical process (case_id, PID_U, PID_ext) and are consistent with regard to signature, time window, communication channel and negative lists, does the state engine set the process to a confirmed completion state (SUCCESS_CONFIRMED) and log a summarized success event (E_success).

[0033] Based on this confirmed completion status, the gatekeeper, in a preferred embodiment, calculates an expected payment request and an expected settlement or payment date. For this purpose, configuration data such as compensation or other settlement parameters, cancellation and revocation periods, settlement intervals, and optionally thresholds or upper limits are used, which are parameterized by the external sales domain (C_ext) or the regulated primary company (U). At least one "payout_expected" state is maintained for the process, indicating that settlement for this process is expected after the relevant deadlines have expired.

[0034] After the cancellation and revocation periods stored in the system have expired, the time and status component (TI) initiates a renewed technical review of the contract or service status. For this purpose, updated status messages from C_ext and EXT_PROVIDER are used, transmitted to the gatekeeper, and compared with the existing record. If the process remains reported as effective in both domains and no negative event (E_neg) is present, the process remains in the closed state, and the gatekeeper maintains the expectation of a corresponding invoice.

[0035] If the external sales domain (C_ext) or a billing instance linked to it reports a target event (E_settlement) for the relevant transaction to the gatekeeper during a billing run, the Settlement Verifier (SV) checks the consistency of this settlement message with the previously established verification structure, in particular with E_success, E_neg, and the checksums and external time anchors (ledger_anchor) anchored in the revision ledger (AL). Only if the settlement message is consistent is the transaction transferred to a "payout_received" state and, in implementations with explicit execution marking, additionally marked as a fully executed action (PAID).

[0036] If no consistent billing notification is received for a confirmed transaction within a configured time window after the cancellation and revocation periods have expired, the gatekeeper can mark the transaction as "payout_overdue". This status serves for the audit-proof technical documentation of transactions for which a cross-domain, doubly confirmed completion exists, but no billing or an implausible one has been issued. The gatekeeper itself does not make any payments or manage any payment flows, but provides a neutral, tamper-proof control and verification instance for completion and billing status. Solution - multi-stage testing chain in four technical blocks

[0037] Block 1: Consent, identity binding and process identification • Identity-based consent is digitally recorded, provided with a timestamp, source, wording version and checksum, and logged in an append-only event log. • An out-of-band confirmation is obtained via a separate communication channel (e.g., telephone callback, separate electronic message, or second factor). The content of this confirmation is cryptographically linked to the checksum from the initial confirmation. • A unique case identifier (case_id) is generated, to which all subsequent events are linked. In preferred implementations, the case_id is created as a pseudonymous identifier from a set of attributes and an organization-specific salt using a hash function. In this case, separate identifiers such as PID_U and PID_ext are used in the participating trust domains.

[0038] Block 2: Event Log, Append-Only Storage, and Multi-Source Acknowledgement • All relevant events (consents, confirmations, status changes, negative events) are logged in a sequentially numbered, append-only event log. Gaps, duplicates, and backdating are automatically detected. Idempotence mechanisms and replay protection ensure that identical entries cannot be applied multiple times. • At least two independent trust domains provide signed success signals. These are checked for signature validity, origin, and time consistency and linked to the process identifier. In preferred implementations, the following are also performed: ◯ a maximum time window (Δt) between notification, consultation and conclusion, ◯ the consistency of the communication channel, ◯ optional geofactors as well as ◯ Negative lists (objection, revocation, do-not-contact) taken into account. Block 3: Revision ledger, hash chain and external time anchor • Selected checksums and metadata of the events from Block 1 and Block 2 are written to a revision ledger that is physically or logically separate from the production event storage. • The entries are structured as a hash chain, with each entry referencing the hash of the previous entry. • At regular intervals, Merkle roots are created over defined sections of the revision ledger and transmitted to an external timestamp instance (TSA). The timestamps generated by the TSA serve as an external time anchor. • If the TSA fails, a blocking state is set; releases remain blocked until the anchoring is completed, the external timestamp is verified, and the integrity of the hash chain is confirmed.

[0039] Block 4: Technical waiting period, negative events and verified release • A technical waiting period is enforced between the confirmation of a success and the possible release of an action. • During this waiting period, a negative monitor monitors events such as revocation, cancellation, chargeback, or subsequently detected integrity errors. • If a negative event occurs, the process is placed in a lock or quarantine state (e.g., WITHDRAWN, QUARANTINED). • Before final release, a verified target event is checked, such as a signed payment confirmation from a payment service provider, a completed, signed billing run, or a technically confirmed service activation. • The target event is compared with the process identifier and the proof sequence from blocks 1 to 3. Only if all conditions are met and no negative event occurs does the state machine switch to a releaseable state (PAYABLE) and the release engine is allowed to execute the action. State machine

[0040] In a preferred embodiment, the state machine goes through the following main states: • CREATED - Process created, no valid consent yet, • CONSENT_OK - Consent event (E_C) captured and logged in the event log (ES), • OOB_OK - Out-of-Band event (E_oob) successfully completed and bound to the checksum of E_C, • CASE_ACTIVE - Process identifier (case_id, PID_U, PID_ext) is generated and assigned to the relevant events, • EVENTS_OK - Event log in the Event Store (ES) is complete, without gaps and without integrity errors, • SUCCESS_CONFlRMED - professional success confirmed after multi-source verification (E_success), in particular based on success signals from at least two independent trust domains, for example an external sales or cooperation domain (C_ext) and an external provider or product supplier domain (EXT_PROVIDER), • LEDGER_ANCHORED - relevant checksums and metadata are stored in the revision ledger (AL) and anchored via an external time anchor (TSA, E_anchor, ledger_anchor), • WAITING_PERIOD - technical waiting period active, monitoring for negative events (E_neg) by the time and state component (TI), • PAYABLE - all conditions of the four-block structure are met, waiting period has expired, no negative event (E_neg) has been recorded, target event prerequisites are met, process is generally releaseable, • PAID - in implementations involving payments: the verified target event (E_settlement), for example a confirmed invoice or payment confirmation, has been checked and the operation has been marked as fully completed.

[0041] In addition, there are special states: • QUARANTINED - Quarantine status in case of integrity problems, duplicates or conflicts with negative lists (E_neg), • BLOCKED - Blocking state in case of failure or critical error in the revision path or at the external time anchor (TSA), • WITHDRAWN - Status after revocation, cancellation or chargeback within defined time periods, • DENIED - a process definitively rejected, especially in cases of irresolvable conflicts, invalid signatures, or rule violations.

[0042] In preferred embodiments, states or state markers for the billing status are additionally managed, for example: • payout_expected - double confirmed completion (SUCCESS_CONFIRMED) is present; based on configuration data such as compensation or billing parameters, cancellation and revocation periods as well as billing intervals, a settlement for the transaction is expected, • payout_received - a target event (E_settlement), in particular a settlement message from a sales or settlement domain, has been received and verified by the Settlement Verifier (SV) in accordance with the existing evidence structure (E_success, E_neg, AL, ledger_anchor), • payout_overdue - no consistent settlement notification has been received within a configured time window after the relevant deadlines have expired; the process is documented as a technically overdue settlement, without the gatekeeper system itself executing any payment flows.

[0043] Transitions towards PAYABLE and PAID only occur if the conditions of all four blocks are met. States such as payout_expected, payout_received, and payout_overdue serve as additional technical documentation of the settlement and billing status and do not change the core functionality of the four-block structure. Architecture - Modules and Interfaces

[0044] In a preferred embodiment, the architecture of the gatekeeper system comprises the following modules and services: Process Service (PS): State machine and orchestration of the test chain in four blocks; management of state transitions, fault paths and the SUCCESS_CONFIRMED state. PAYABLE and PAID, as well as the supplementary billing states payout_expected, payout_received, and payout_overdue. The Process Service sets lock, block, and quarantine states and coordinates the calls to downstream modules.

[0045] Consent Module (CM): The Consent Module (CM) captures consent (E_C), manages a library of versioned consent and information texts including their associated wording checksums, signature and timestamp logic, triggers and processes out-of-band confirmation (E_oob), and binds consent events to the process identifiers (case_id, PID_U, PID_ext). For this purpose, the CM provides a consent form supplied by the gatekeeper as a user interface, which can be integrated into the frontends of the participating trust domains and, for a given use case, displays a consent form released from the library. The information text displays the selected text version. The consent form enforces that only approved text versions are used to generate consent events, captures the customer-selected topics and contact channels as parameters, and passes the resulting consent events (E_C) with template ID, text version ID, identifying characteristics, and timestamp to the event store (ES). The consent module then passes the logged consent events to the event store (ES).

[0046] Pseudonymization Service (PSE, optional): Generation of pseudonymous identifiers (PID_U, PID_ext) from an underlying set of characteristics using organization-specific salts (S_U, S_ext) and Hash functions. The Pseudonymization Service ensures that different, non-reversible identifiers are used in different trusted domains, which can nevertheless be correlated via the gatekeeper.

[0047] Access Control Service (ACS, optional): Role- and attribute-based access control to the functions of the gatekeeper system; issuance of time-limited tokens (T_exp) for the minimum necessary data views. The Access Control Service can also manage licenses and Status checks of intermediary parties before accepting events, in particular, submit advisory and final reports.

[0048] Event Store (ES): Append-only event log for recording all relevant events (E_C, E_oob, E_success, E_neg, E_settlement, and other status and System events) with sequential numbering, idempotence mechanisms and Replay protection. The Event Store detects gaps, duplicates, and backdating and reports integrity errors to the Process Service (PS), which moves processes to the QUARANTINED state if necessary.

[0049] Confirmation Adapters (CA): Adapter layer for integrating independent trust domains. The Confirmation Adapters receive cryptographically signed success signals from external systems, particularly from an external sales or... Cooperation domain (C_ext) and an external provider or Product supplier domain (EXT_PROVIDER) and optionally from other specialist domains, Billing or payment systems. They check signatures, origin, timestamps, permissible time windows (Δt), channel consistency and assignment to transaction identifiers (case_id, PID_U, PID_ext) and pass verified signals to the Event Store (ES) and the Process Service (PS) to form a summarized success event (E_success).

[0050] Revision Ledger (AL): A separate revision ledger contains selected checksums, hashes, timestamps, and references to events in the Event Store (ES). The entries are linked using a hash chain, making subsequent changes technically detectable. Plain data is not stored in the revision ledger. The revision ledger forms the basis for the external time anchor and for later verification of the integrity and completeness of the event sequence.

[0051] Anchoring Service (AS): A service for generating Merkle roots across defined sections of the revision ledger (AL) and for communicating with an external timestamp instance (TSA). The anchoring service transmits Merkle roots to the timestamp instance and writes the signed timestamps generated by the timestamp instance back to the revision ledger along with the Merkle roots as anchor events (E_anchor, ledger_anchor). In case of failure or inconsistency of the external timestamp instance, the process service (PS) sets a blocking state (BLOCKED) based on the information provided by the anchoring service.

[0052] Timer (TI): A time and state component for managing technical waiting periods and monitoring negative events (E_neg) during defined time periods. The timer triggers time-controlled checks, for example, after the expiry of cancellation and revocation periods, and initiates follow-up checks of the status messages from C_ext and EXT_PROVIDER. Based on these checks, the timer supports state transitions to WAlTING_PERIOD, PAYABLE, and additional billing states such as payout_expected, payout_received, and payout_overdue.

[0053] Settlement Verifier (SV): Module for verifying verified target events (E_settlement), particularly settlement messages from a sales or billing domain. The Settlement Verifier compares E_settlement with the transaction identifier (case_id, PID_U, PID_ext), the existing evidence chain from the Event Store (ES) and Revision Ledger (AL), including external anchor events (ledger_anchor), as well as with negative events (E_neg). Only if the result is consistent does the Settlement Verifier support the transition of a transaction to the payout_received state and, if applicable, to PAID.

[0054] Release Engine (RE): A component for the idempotent triggering of event-driven actions, such as the technical release of a service, API access, or a billing process. The Release Engine is only activated when the Process Service (PS), based on the four-block structure, the state machine, and verified target events (E_settlement), has determined a releaseable state (PAYABLE). In implementations where the actual payment processing takes place in external systems, the Release Engine does not trigger any cash flows but rather controls technical releases or marks processes as fully executed (PAID).

[0055] The modules can be operated in a distributed system architecture and communicate with each other via defined interfaces, in particular / consent, / consent / oob, / case / id, / event, / success / a, / success / b, / ledger / anchor, / settlement / verify, / release / check and / release / start. The specific distribution of the modules across physical or logical systems is freely selectable, as long as the described functions and trust domains are implemented separately and in a technically verifiable manner. Security and compliance aspects

[0056] The security and compliance measures described below are optional, preferred embodiments for hardening the implementation and do not affect the core functionality of the four-block structure. The gatekeeper system according to the invention can be operated in one or more preferred embodiments within a conventional secure system architecture. The aforementioned security measures serve to safeguard the implementation but are not part of the core technical invention; rather, they represent optional features.

[0057] At the transport layer, current transport encryption can be used to protect communication between the involved modules and trusted domains against unauthorized interception or modification. At the storage layer, encryption of the stored data can be provided, with keys preferably managed in a secure key management system.

[0058] Access to the system can be controlled through role-based or attribute-based access control. Multi-factor authentication can be implemented for particularly sensitive roles or functions. The specific design of the access control is freely selectable and not tied to a particular product or protocol.

[0059] At the data level, the system's existing pseudonymization of transaction identifiers using organization-specific salts can be employed to limit personal data to the necessary minimum. For individual, particularly sensitive fields of the minimum data set (D_min), further encryption can optionally be provided. In a preferred embodiment, attribute-based encryption is used for this purpose, where temporary access to plaintext data is granted only if the required attribute keys are present. The gatekeeper's release logic can be designed to technically prevent releases without valid attribute keys.

[0060] At the integrity level, in addition to the core hash chain and external time anchoring, the system can implement further technical measures such as repetition and idempotence checks, protection against retrigger attacks, and monitoring mechanisms for unusual call patterns. These measures serve to harden the implementation but do not change the underlying, function-defining four-block structure.

[0061] To support regulatory requirements, the system can include technically logged revocation and deletion paths, license and status checks of intermediaries, and functions for enforcing data protection principles, in particular data minimization and purpose limitation. In a preferred embodiment, a policy store is also provided that references the currently valid rule and legal version at the time an action is released and stores a reference to this in the audit trail structure of the audit trail. This makes it technically traceable during subsequent audits under which rule and legal version a specific release process took place, without having to disclose the technical content of the rules in the audit trail. These functions utilize the existing event and audit trail structure and can be configured differently depending on the use case. Technical effect and distinction from the state of the art

[0062] With the current state of technology, it was not possible in known systems to trigger legally relevant and data protection-compliant actions across multiple independent systems in a technically verifiable, consistent, tamper-proof, and simultaneously scalable manner. Known solutions are essentially limited to organizational processes, simple logging, business workflows, or isolated billing and payment systems, without technically enforcing the necessary conditions and without independent, neutral, cross-domain verification by a gatekeeper who is not himself assigned to any trusted domain.

[0063] The technical effect of the invention lies particularly in • the enforced coupling of multiple verification mechanisms (consent, out-of-band confirmation, multi-source confirmation, append-only event log, revision ledger with hash chain, external time anchor, waiting period with negative monitoring, verified target event) by a deterministic state machine, • the resource-saving prevention of faulty or manipulated actions at the system level, before memory- or network-intensive processes are triggered, • the creation of tamper-resistant, machine-readable evidence across the entire event chain based on a revision ledger separate from the production event memory with externally anchored entries.

[0064] Known systems log events and consents, but do not use a four-tiered gatekeeper structure in which • Consent and out-of-band confirmation with an identity- or process-related identifier, • a complete append-only event store with idempotence mechanisms and multi-source confirmation, • a separate revision ledger with hash chain and external time anchoring as well as • a waiting period with negative monitoring and verification of a verified target event as mandatory technical prerequisites for the execution of an action, interacting and enforced by a central, neutral state machine. The invention thus goes beyond pure business logic, conventional logging mechanisms, and known consent, ledger, or accounting systems.

[0065] In addition, the gatekeeper system supports the accountability and burden of proof for the data controller as required by data protection law: The combination of an append-only event log (ES), a separate revision ledger (AL) with a hash chain, externally anchored entries (ledger_anchor), and the deterministic state machine creates a machine-readable chain of evidence. This chain allows for the technical traceability of consent (E_C), out-of-band confirmation (E_oob), multi-source success events (E_success), negative events (E_neg), and, where applicable, settlement states (payout_expected, payout_received, payout_overdue) for each process. Approvals are technically prevented until the verification structure configured for the respective use case is complete and consistent.

[0066] In preferred embodiments, the technical effect also includes a cross-domain control and verification function for closing and settlement status, without the gatekeeper system itself executing or managing payment flows: • The technical success of a process is only considered confirmed if at least two independent trust domains - in particular an external sales or cooperation domain (C_ext) and an external supplier or product provider domain (EXT_PROVIDER) - provide consistent, cryptographically signed success signals and are logged as a multi-source success event (E_success) in the event store (ES). • Based on this doubly confirmed closure, expected settlement processes and times are determined and managed as separate states of the state machine (e.g. payout_expected), without the gatekeeper system itself processing payment flows. • Billing messages from a sales or billing domain are technically checked against the previously established verification structure (including E_success, E_neg, revision ledger AL and external time anchor ledger_anchor); missing or implausible billings can be marked as a separate technical condition (e.g. payout_overdue).

[0067] The invention thus extends technical control from the mere release of an action to cross-domain, tamper-resistant monitoring of transactions and their settlement, without taking over the payment processing itself. The gatekeeper system acts as a neutral control and verification instance between the trusted domains and enforces that the transaction, audit trail, and settlement are technically consistent before a release-ready state is reached.

[0068] In addition, the invention extends the technical capabilities beyond the current state of the art by enabling the same multi-stage verification chain and state machine to be used as a reusable technical framework in different industries and scenarios without requiring modification of the core logic that defines the function. This results in a scalable, cross-domain technical release logic that can be used in both regulated and unregulated business environments for payments, compensation, the technical activation of services, API access, or configuration changes. Example A - Cooperation between the primary company, external sales domain and external supplier or product vendor domain

[0069] In one implementation example, an intermediary (V), acting on behalf of a regulated primary undertaking (U), such as an insurance company, captures a customer's (K) consent to be contacted by an external sales or cooperation domain (C_ext) that brokers complementary products or services, such as energy products. The consent is digitally captured as a consent event (E_C), provided with a timestamp, source, wording version identifier, and checksum, and logged in the append-only event store (ES). An out-of-band event (E_oob) is retrieved via a separate communication channel and cryptographically linked to the checksum of E_C. Pseudonymous identifiers (PID_U, PID_ext) and a case identifier (case_id) are generated from a set of attributes using organization-specific salts, so that only a minimal data set (D_min) needs to be exchanged between the parties involved.

[0070] The external sales domain (C_ext), for example, an external energy supplier or another cooperation system, provides expert advice and reports a success signal to the gatekeeper (GK) upon successful completion. Independently of this, an external provider or product supplier domain (EXT_PROVIDER), for example, a product or billing system offering a service, reports the effectiveness status of the brokered contract or service for the same transaction identifier (case_id, PID_ext). The multi-source verification in Block 2 of the gatekeeper system checks signatures, origin, time window (Δt), consistency of the communication channel, and negative lists (E_neg) and generates a consolidated success event (E_success) upon successful verification. The associated checksums and references are transferred to the revision ledger (AL) in Block 3 and anchored via an external timestamp instance (TSA).

[0071] After reaching the SUCCESS_CONFIRMED state and transitioning to LEDGER_ANCHORED, Block 4 enforces a technical waiting period (WAITING_PERIOD) during which negative events (E_neg), specifically revocations, cancellations, chargebacks, or integrity errors, are checked. Simultaneously, the gatekeeper calculates, based on stored configuration data such as compensation or billing parameters, cancellation and revocation deadlines, and billing intervals, whether and from what point in time billing is expected for the transaction. If no negative events occur and all four block conditions are met, the transaction is transferred to a release-ready state (PAYABLE) and additionally marked as payout_expected.

[0072] In a subsequent settlement run, the external sales domain (C_ext) or an associated settlement instance transmits a target event (E_settlement) to the gatekeeper, containing a settlement message for the relevant transaction. The Settlement Verifier (SV) checks E_settlement against the existing verification structure, specifically E_success, E_neg, the checksums stored in the revision ledger (AL), and the external time anchor (ledger_anchor). If the result is consistent, the transaction is marked as payout_received and, in implementations with explicit execution marking, is transferred to the PAID state, which documents that the released action (e.g., payment of a cooperation fee or posting of a settlement) is fully and auditably traceable.

[0073] If no consistent settlement notification is received within a configured time window after the relevant cancellation and revocation periods have expired, the process remains in a closed state (SUCCESS_CONFIRMED) but is marked as payout_overdue. This state serves as technical and audit-proof documentation that no settlement, or no plausible settlement, exists for a doubly confirmed transaction. The gatekeeper system itself does not trigger or process any payment flows at any stage, but rather provides a neutral, tamper-proof control and verification instance for completion and settlement status across multiple trust domains, while the actual payment processing remains in external systems. Example B - Technical activation of API access in a security-critical system environment

[0074] In another embodiment, the gatekeeper system (GK) according to the invention is used not for remuneration or billing purposes, but for the technical activation of API access in a security-critical system environment. An administrator or an authorized specialist role submits a request in an administrative system to activate write API access to a production system, for example, to a configuration or deployment endpoint of a cloud or platform environment.

[0075] The request is recorded as an event in the gatekeeper system (GK) and assigned a case ID (case_id), which can be represented as pseudonymous identifiers (PID_U, PID_ext) in various trust domains. In a preferred implementation, the request is additionally secured by an out-of-band confirmation (E_oob), for example, by separate confirmation from a second person (dual-control principle) or by a second factor via a separate communication channel. Both the original request and the out-of-band confirmation are logged as events (E_C, E_oob) in the append-only event store (ES).

[0076] At least two independent trust domains provide corresponding success signals for the unlock request. In one embodiment, this includes a success signal from an internal authorization system that confirms the role and license requirements, and another success signal from a technical monitoring system that assesses the current security or compliance status of the target system. These success signals are transmitted via the adapter layer (CA) to the event store (ES), where they are linked to the case identifier (case_id, PID_U, PID_ext) and aggregated as a multi-source success event (E_success), provided that signatures, time windows (Δt), communication channels, and negative lists (E_neg) are consistent.

[0077] Selected checksums and references to events logged in the Event Store (ES) are transferred to the Revision Ledger (AL) and stored there as hash-chained entries. At regular intervals, Merkle roots (MR) are constructed over groups of ledger entries and transmitted via the Anchoring Service (AS) to an external timestamp instance (TSA). The signed timestamps generated by the timestamp instance are stored as anchor events (E_anchor, ledger_anchor) in the Revision Ledger (AL), ensuring that the integrity and chronological classification of the record-keeping structure remain verifiable.

[0078] After reaching a confirmed success state (SUCCESS_CONFIRMED) and anchoring the relevant proof structure (LEDGER_ANCHORED), the gatekeeper's (GK) state engine enforces a technical waiting period (WAITING_PERIOD). During this waiting period, the timer module (TI) monitors for negative events (E_neg), such as revocation of the activation request, revocation of permissions, changes to security policies, or detected integrity errors. If such a negative event occurs, the process is transferred to a lock or quarantine state (e.g., QUARANTINED or WITHDRAWN), thus technically preventing activation.

[0079] Only when all conditions of the four-block structure are met, no negative events (E_neg) are present, and a verified target event (E_settlement) exists—for example, a technically signed release confirmation from a higher-level orchestration or change management system—does the state engine set the process to a releaseable state (PAYABLE or equivalent technical release status). The Release Engine (RE) then triggers the technical activation of API access or implements a corresponding configuration change in the target system. The release is idempotent, meaning that repeated target events with the same idempotency key do not result in multiple releases.

[0080] This example illustrates that the gatekeeper system (GK) according to the invention is not limited to financial or compensation-related processes, but can be used as a general technical framework for the controlled release of safety-critical system actions. The same multi-stage verification chain and the same state machine can be used without modifying the core logic that determines the function, by simply parameterizing the type of events, the trust domains involved, and the verified target events. Detailed technical description (4-block structure with reference symbols) Technical title

[0081] Technical system for the revision-proof, tamper-resistant release of event-dependent actions between independent systems by means of a multi-stage test sequence divided into four blocks and a deterministic state machine. Brief description

[0082] The system technically enforces that an event-driven action (e.g., payment) is only released if a multi-stage verification chain consisting of four technical blocks has been completed fully, consistently, and without any negative events. Within these blocks, a more granular ten-step verification process is implemented, specifically including consent, identity or identity binding, event log, multi-source confirmation, revision ledger, external time anchor, waiting period, and verified target event. Deviations result in an unavoidable block or quarantine state.

[0083] Processing can be pseudonymized by converting business characteristic sets into organization-specific, hashed process identifiers (e.g., PID_U, PID_ext) and exchanging only the minimum necessary data records between the participating trusted domains. Role- and attribute-based access control, time-limited tokens (T_exp), and optional bonus / penalty and cancellation logics can be integrated without altering the core logic of the audit chain. Technical task (detailed description)

[0084] The technical problem described in the invention is further specified in this detailed description by stating that the system additionally: • the consent event (E_C) and the out-of-band event (E_oob) as explicit, separate events, • A summarized success event (E_success) is logged after multi-source verification, • Negative events (E_neg) such as revocation, cancellation, chargeback and integrity errors are taken into account in all blocks, • builds a revision ledger (AL) with hash-chained entries (prev_hash), • periodically sets an externally anchored anchor (E_anchor, ledger_anchor) via an external timestamp instance (TSA) and • A verified target event (E_settlement) is used as a prerequisite for the PAYABLE state. Solution - multi-stage testing chain in four technical blocks (detail)

[0085] Block 1: Consent, identity binding and process identifier (E_C, E_oob, case_id, PID_U, PID_ext) • Consent Capture (Consent Event E_C): Identity-based consent is captured as a consent event (E_C) with a timestamp (t), source, wording version identifier, and checksum. The consent is logged in an append-only event store (Event Store, ES). • Separate second confirmation (out-of-band confirmation, event E_oob): Consent is confirmed via a separate communication channel (e.g., telephone callback or separate communication channel) in the form of an out-of-band event (E_oob). The second confirmation is cryptographically bound to the checksum from the consent event (E_C) and also logged in the append-only event log. • Process identifier and optional pseudonymization (case_id, PID_U, PID_ext): A unique process identifier (case_id) is generated, to which all further events are linked. In preferred implementations, the process identifier is created as a separate pseudonymous identifier in each trust domain by deriving identifiers such as PID_U and PID_ext from a set of attributes and an organization-specific salt (e.g., S_U, S_ext) using a hash function. This ensures that each trust domain uses its own unique, non-reversible identifier. Block 2: Event log, append-only storage and multi-source acknowledgment (E_success, E_neg) • Append-Only Event Store (ES): All relevant events, in particular consent events (E_C), out-of-band events (E_oob), status changes, negative events (E_neg), and success signals from participating systems, are stored in an append-only event store with sequential numbering. Each incoming event is assigned an idempotence key derived from the case ID (case_id) and event characteristics. Gaps, duplicates, or backdating are detected and result in an integrity error. Idempotence keys and replay protection ensure that identical inputs do not have multiple effects. • Multi-source success confirmation (dual confirmation, event E_success): At least two independent trust domains (e.g., an external sales or specialist system and an internal billing or settlement system) provide signed success signals. These are checked for signature, origin, and time consistency and linked to the case identifier (case_id, PID_U, PID_ext). In preferred configurations, an acceptable time window (Δt) between notification, consultation, and completion, the consistency of the communication channel, optional geo-factors, and negative lists (e.g., objection, revocation, do-not-contact, summarized as E_neg) are also considered. Only if all checks are successful is a summary success event (E_success) logged in the append-only event log. Block 3: Revision ledger, hash chain and external time anchor (AL, prev_hash, E_anchor, ledger_anchor) • Separate revision ledger (AL): Selected checksums, references to sequential numbers in the event store, and timestamps of the events logged there (especially E_C, E_oob, E_success, E_neg) are stored in a dedicated revision ledger that is physically or logically separate from the production event storage. The revision ledger contains only hashes, checksums, timestamps, and references, but no plain text data. • Hash-linked proof series (prev_hash): The entries in the revision ledger are linked by a hash chain, where each entry contains a hash value derived from at least the immediately preceding entry. The hash value of the preceding entry is referenced as `prev_hash`. Any subsequent change to an entry would break the hash chain and is therefore technically detectable. • External time anchor (TSA, event E_anchor, ledger_anchor entry): At regular intervals, a Merkle root is created across defined sections of the revision ledger. This Merkle root is transmitted to an external timestamping authority (TSA), which generates a signed external timestamp. The combination of the Merkle root and the external timestamp is written back to the revision ledger as an anchor event (E_anchor) and referenced in a special ledger entry (ledger_anchor). If the timestamping authority fails or there are inconsistencies in the external timestamps, a blocking state (BLOCKED) is set; releases are blocked until the external anchor has been recreated and verified. Block 4: Technical waiting period, negative events and verified release (E_neg, E_settlement)

[0086] Technical waiting period and negative events (E_neg): A technical waiting period is enforced between the logging of the success confirmation (E_success) and the potential release of an action. During this waiting period, the system continuously checks for negative events (E_neg). Negative events include, in particular, revocation of consent, cancellation, chargeback, and detected integrity errors in the event store or revision ledger. If a negative event (E_neg) occurs during this time, the process is placed in a blocked or quarantine state (e.g., WITHDRAWN or QUARANTINED), in which release is permanently prevented.

[0087] Verified target event and release (E_settlement): Before final release, a verified target event (E_settlement) is checked, such as a signed payment confirmation from a payment service provider or a completed, signed settlement run from a billing system. This target event (E_settlement) includes a signature, a timestamp, and a reference to the transaction identifier (case_id, PID_U, PID_ext). It is compared with the transaction identifier and the entire evidence chain from the event store and revision ledger, including the external anchor via ledger_anchor. Only if all conditions are met, no negative event (E_neg) is present, and the verified target event uniquely confirms the transaction, does the state engine set the transaction to a releaseable state (PAYABLE) and allow the release engine (RE) to execute the event-dependent action (e.g., triggering the payment).The release is idempotent; repeated target events with the same idempotence key have no additional effect.

[0088] Optional risk analysis: In an optional embodiment, a risk analysis module (RS) is also provided. Based on the event data stored in the event log (ES) and the revision ledger (AL), as well as any recorded negative events (E_neg), this module determines a risk score for each process. The risk score is transmitted to the Process Service (PS), which is configured so that a transition to the release-ready state (PAYABLE) is only permitted if, in addition to fulfilling the gate conditions in blocks 1 to 4, a configured risk threshold is not exceeded. The risk analysis module (RS) can be rule-based or implemented as a component based on machine learning or artificial intelligence. However, it does not itself trigger releases but merely provides additional risk indicators to enhance the security of the gatekeeper system. Inventive technical effect

[0089] The combination of the described blocks, modules, and states results in particular in: • a technical enforcement of the release of an event-dependent action by a gatekeeper with a state engine and state guards, instead of mere business rules or manual checks, • Multi-source authentication from independent trusted domains with PKI validation, combined with time windows (Δt), channel consistency, optional geofactors and negative lists (E_neg), • a separate revision ledger (AL) with hash chain (prev_hash) and external time anchor (TSA, E_anchor, ledger_anchor) that provides tamper-proof, machine-readable evidence without requiring plaintext data in the evidence structure, • a deterministic, idempotent release with blocking, quarantine, and revocation pathways (QUARANTINED, WITHDRAWN, BLOCKED, DENIED) in case of integrity violations, TSA failure, revocation, or cancellation, • as well as data-efficient cooperation between independent systems through pseudonymization (PID_U, PID_ext) and tokenization (T_exp), without losing the correlation of the relevant events.

[0090] This achieves a technical effect that goes beyond simple logging mechanisms and usual payment workflows, technically securing both integrity and traceability as well as data protection requirements. Reference symbol list

[0091] Roles and domains • K affected person • Upstream acquisition component • U regulated first company • C_ext external sales or cooperation domain • EXT_PROVIDER external provider / product supplier • GK Gatekeeper System Modules / functional components • PS Process Service (process control / state machine in the GK) • CM Consent Module • PSE Pseudonymization Service • ACS Access Control Service (optional, for access control) • ES Event Store (Append-Only Event Store) • AL revision ledger (audit ledger) • CA Confirmation Adapter (general, adapter layer for success signals) • CA_oob Out-of-Band Confirmation Adapter for E_oob • CA_U domain-specific confirmation adapter for domain U • CA_ext domain-specific confirmation adapter for domain C_ext • NL Negative List Module • AS Anchoring Service (for Merkle / TSA connection) • TSA external timestamp instance or its connection • TI Timer module for monitoring the waiting period and E_neg • SV Settlement Verifier (for checking E_settlement) • RE Release Engine (for the technical release of actions) • RS Risk Analysis Module (optional) Ledger-specific entries and structures • AL_1 first, exemplary ledger entry in the revision ledger (AL) • AL_2 further, exemplary ledger entry in the revision ledger (AL) • ledger_anchor: Anchor entry stored in the revision ledger (AL) with an external time anchor • MR Merkle Root (Root of a Merkle tree across ledger entries) • prev_hash Hash of the previous ledger entry in the hash chain Events and data • E_C consent event • E_oob Out-of-Band Confirmation • E_success Multi-source success event • E_neg negative event • E_settlement verified target event (settlement event) • E_anchor externally anchored anchor event Data flows and signals • E Event data flow • S success signal • success_a Success signal from domain U • success_b Success signal from the domain C_ext Identifiers and pseudonyms • case_id pseudonymous process identifier • PID general pseudonymous identifier of a data subject (general term) • PID_U pseudonymized identifier for the regulated primary undertaking • PID_ext pseudonymized identifier for an external domain States of the state machine ( Fig. 4) • CREATED Process created, initial state • CONSENT_OK Consent check successful • OOB_OK Out-of-Band confirmation positive • CASE_ACTIVE Operation active, event recording enabled • EVENTS_OK event-related checks successful • SUCCESS_CONFIRMED Multi-source success (E_success) confirmed • LEDGER_ANCHORED Evidence structure anchored in the revision ledger (AL) • WAITING_PERIOD Technical waiting period active, monitored by TI • PAYABLE condition for payment / compensation fulfilled • PAID payout / compensation carried out • QUARANTINED Process in quarantine after a negative event • WITHDRAWN process withdrawn / revoked • BLOCKED Operation technically blocked • DENIED Operation rejected Other parameters and sizes • t Timestamp of an event • Δt permissible test time window • D_min minimum required data set for processing • S_U organization-specific salt of domain U • S_ext organization-specific salt of the external domain C_ext • T_exp is a time-limited access or authorization token • R_storno Cancellation reserve for compensation or billing models · integrity = OK Marking of a process with a fully verified series of evidence

Claims

[1] System for the audit-proof, tamper-resistant release of an event-dependent action between independent systems, comprising: • a consent module (CM) set up to capture identity-based consent from a data subject with timestamp (t), source, wording version identifier and checksum as a consent event (E_C) and to log the consent event (E_C) in an append-only event store (Event Store, ES), • Communication means set up to obtain a separate second confirmation of consent via a communication channel different from the initial recording as an out-of-band event (E_oob) and to cryptographically bind the out-of-band event (E_oob) to the checksum generated in the consent event (E_C), • a generation device set up to generate a unique case identifier (case_id) to which all associated events are bound, wherein the generation device is preferably designed such that pseudonymous identifiers (PID_U, PID_ext) are derived from a common set of features in different trust domains using organization-specific salts (S_U, S_ext) and hash functions, • the Append-Only Event Store (ES), set up to store all relevant events including consent events (E_C), out-of-band events (E_oob), status changes, negative events (E_neg), and success signals from participating systems, with monotonically increasing, sequential numbering, idempotence keys, and replay protection to detect gaps, duplicates, and backdating, • at least one adapter layer for success signals (CA), configured to receive at least two cryptographically signed success signals from independent trust domains, to check the signatures, origin and time consistency of the success signals, and to link the success signals with the case identifier (case_id, PID_U, PID_ext) taking into account a permissible time window (Δt), the consistency of the communication channel and optional negative lists, • a revision ledger module (AL) configured to store selected checksums, references to sequential numbers of the event store (ES) and timestamps of the logged events, in particular E_C, E_oob, E_success and E_neg, in a revision ledger physically or logically separate from the event store (ES), wherein the entries of the revision ledger are linked by means of a hash chain, where each entry comprises a hash value derived from at least the immediately preceding entry (prev_hash), • an anchoring service (AS) set up to periodically generate Merkle roots over defined sections of the revision ledger and to transmit the Merkle roots to an external timestamp instance (TSA), whereby the signed timestamps generated by the timestamp instance are stored together with the Merkle roots as anchor events (E_anchor, ledger_anchor) in the revision ledger, • a timer (TI) with negative monitor, set up to enforce a technical waiting period between a confirmed success event (E_success) and a possible release of the event-dependent action, as well as to monitor for the occurrence of negative events (E_neg), in particular revocation, cancellation, chargeback and integrity errors in the event log (ES) or revision ledger (AL), • a Settlement Verifier (SV) set up to check a verified target event (E_settlement) that includes a signature, a timestamp and a reference to the operation ID, and to match the target event (E_settlement) with the operation ID (case_id, PID_U, PID_ext) and the evidence chain from the event store (ES) and revision ledger (AL) including the external anchor (ledger_anchor), • a Release Engine (RE), configured to trigger the event-dependent action idempotently only when a Process Service (PS) based on a state machine has determined that the consent and second confirmation level, the event log with multi-source confirmation, the revision ledger with external time anchor and the waiting period with negative monitoring have been fulfilled without objection, and the verified target event (E_settlement) has been confirmed, where the Process Service (PS) manages the system in states including CREATED, CONSENT_OK, OOB_OK, CASE_ACTIVE, EVENTS_OK, SUCCESS CONFIRMED, LEDGER_ANCHORED, WAITING_PERIOD, PAYABLE and PAID, as well as in lock, block and quarantine states (QUARANTINED, BLOCKED, WITHDRAWN, DENIED), and allows the release of the event-dependent action exclusively from a releaseable state (PAYABLE) towards PAID. [2] System according to claim 1, characterized bythat the consent module (CM) is configured such that the consent is digitally signed, the wording used for the consent is linked to an explicit version identifier, and the checksum is generated from at least the wording version, identifying characteristics, and a timestamp, wherein the out-of-band event (E_oob) includes a comparison with the checksum generated from the consent event (E_C) so that a subsequent substitution of the consent text is technically detectable, wherein the consent module (CM) furthermore manages a library of versioned consent and information texts and is integrated into client or frontend systems of at least one trusted domain via a consent form, wherein the consent form selects an approved text version in each case and only transfers such consents (E_C) as valid consent events to the event store (ES).which were collected using a shared text version and by selecting topics and contact channels. [3] System according to any one of the preceding claims, characterized by , that • the case ID (case_id) in a first trusted domain as the first pseudonymous identifier (PID_U) using a first organization-specific salt (S_U) and • is generated in a second trust domain as a second pseudonymous identifier (PID_ext) using a second organization-specific salt (S_ext), whereby the identifiers PID_U and PID_ext can be traced back to the same set of characteristics without having to directly exchange plain data between the trust domains, and only aggregated or pseudonymized correlation information is combined in a central correlation point under strict access rules. [4] System according to any one of the preceding claims, characterized bythat the event memory (ES) • assigns a monotonically increasing, consecutive number to each incoming event, • assigns incoming events an idempotence key formed from the case ID and event characteristics, • if an event with the same idempotence key is transmitted again, it recognizes this as a repetition and does not allow it to take effect again and • If a gap, duplicate or backdating is detected, an integrity error is automatically marked and the associated process is moved to the QUARANTINED state. [5] System according to any one of the preceding claims, characterized by that the adapter layer (CA) for success signals is configured such that • that at least two success signals originate from independent trust domains, • Each success signal includes a cryptographic signature and a timestamp, • the signatures are verified using public keys stored in the respective trusted domains, • the timestamps are checked for consistency with a predefined time base and a permissible time window (Δt) and • the success signals are additionally checked to see if they are assigned to an identical communication channel and a consistent process identifier, and only if all the aforementioned criteria are checked positively at the same time is a summarized success event (E_success) marked in the event memory (ES). [6] System according to any one of the preceding claims, characterized by that the audit ledger (AL) • exclusively stores hashes, checksums, timestamps and references to process identifiers, • does not contain any personal data or information about contracts and • is operated physically or logically separately from professional production databases, so that no direct inferences about personal data are possible when accessing the revision path. [7] System according to any one of the preceding claims, characterized by that the Anchoring Service (AS) • Forms Merkle roots over a defined set of ledger entries, • transfers these Merkle roots to the external timestamp instance (TSA) and • stores the signed timestamp generated by the timestamp instance together with the Merkle root as an anchor event (E_anchor) in the revision ledger (AL), so that during later checks the integrity of the relevant ledger sections can be verified against the external time anchor using the anchor event (E_anchor, ledger_anchor). [8] System according to any one of the preceding claims, characterized by, that the Process Service (PS) sets a blocking state (BLOCKED) in the event of a failure or inconsistency of the external timestamp instance (TSA), in which • no new approvals will be granted, • only continuous logging with indication of the blocking state takes place and • Resumption of releases is only permitted after successful restoration and re-anchoring of the revision ledger (AL). [9] System according to any one of the preceding claims, characterized by , that negative events (E_neg), in particular revocations, cancellations, chargebacks, entries in Do-Not-Contact lists or detected integrity errors, • monitored by the timer (TI) with negative monitor during the waiting period, • are mapped as explicit state transitions in the state machine of the Process Service (PS) and • trigger a transition to a quarantine or withdrawal state (QUARANTINED, WITHDRAWN) upon occurrence, so that an action that has already been prepared but not yet executed is automatically prevented. [10] System according to any one of the preceding claims, characterized by , that an Access Control Service (ACS) is provided which issues time-limited tokens (T_exp) with role and attribute information, which serve as a prerequisite for triggering certain events, in particular consultation and completion messages, and are checked by the Process Service (PS) before processing an event. [11] System according to any one of the preceding claims, characterized by , that a Pseudonymization Service (PSE) is operated centrally or domain-specifically and generates different pseudonymous identifiers (PID_U, PID_ext) with their own salts (S_U, S_ext) for the participating trusted domains. [12] System according to any one of the preceding claims, characterized by , that in addition a policy store is operated which references the currently valid rule and legal version at the time of the release of the action and links this reference with the evidence structure in the revision ledger (AL), so that it is traceable in later audits under which rule version a release was made. [13] System according to any one of the preceding claims, characterized by , that particularly sensitive fields of the minimal data set (D_min) are encrypted using attribute-based encryption and are only temporarily processed in plaintext if corresponding attribute keys are available. [14] System according to any one of the preceding claims, characterized by, that for compensation purposes cancellation reserves (R_storno), upper limits (caps), thresholds and bonus / penalty rules are parameterized and used in a compensation engine as a technical component of the decision to release or block a payout. [15] System according to any one of the preceding claims, characterized by , that Do-Not-Contact lists and other negative lists from multiple sources are technically merged before the action is released and fed into the verification chain as negative events (E_neg). [16] System according to any one of the preceding claims, characterized by , that in one embodiment the event-dependent action includes the payment of remuneration to intermediary or cooperating parties in a regulated industry and in another embodiment the technical activation of a service or API access. [17] System according to any one of the preceding claims, characterized by, that several downstream actions for a process are secured via the same verification structure in the revision ledger (AL) and the same external time anchor by processing successive target events (E_settlement) sequentially in the state machine and each separately transferring them to the state PAYABLE or PAID. [18] System according to any one of the preceding claims, characterized by , that an additional integrity indicator is stored in the revision ledger (AL), which is marked as “integrity = OK” for processes with a fully verified and intact verification chain and is used in subsequent audits as machine-readable proof of a complete verification chain. [19] System according to any one of the preceding claims, characterized by, that the modules CM, ES, AL, CA, AS, TI, SV, RE, PSE and ACS are operated as distributed services in a microservice architecture with separate trust domains and communicate with each other via defined interfaces, in particular / consent, / consent / oob, / case / id, / event, / success / a, / success / b, / ledger / anchor, / settlement / verify, / release / check and / release / start. [20] System according to any one of the preceding claims, characterized by , that the Process Service (PS) is configured to manage additional billing states for each process, in addition to the states CREATED, CONSENT_OK, OOB_OK, CASE_ACTIVE, EVENTS_OK, SUCCESS_CONFIRMED, LEDGER_ANCHORED, WAITING_PERIOD, PAYABLE and PAID, in particular • a payout_expected state indicating that, based on a success event (E_success) previously confirmed twice across domains by multi-source verification from at least two independent trust domains, as well as stored compensation or other billing parameters, cancellation and revocation periods and billing intervals, billing for the process is to be expected, • a payout_received state, indicating that for a settlement confirmed in this way, a target event (E_settlement), in particular a settlement message from a sales or settlement domain, has been received and verified consistently with the existing evidence chain consisting of event log (ES), revision ledger (AL), external time anchor (ledger_anchor) and any existing negative events (E_neg), and • a payout_overdue state indicating that for a transaction doubly confirmed in this way, no consistent settlement message has been received within a configured time window after the relevant deadlines have expired, and the transaction is therefore documented as a technically overdue settlement, whereby the gatekeeper system itself does not execute any payments or manage any payment flows, but technically monitors and documents the settlement and settlement status across the participating trust domains in an audit-proof manner. [21] System according to any one of the preceding claims, characterized by that as independent trust domains at least • an external sales or cooperation domain (C_ext) and • an external provider or product supplier domain (EXT_PROVIDER) is provided, wherein the adapter layer for success signals (CA) is configured to receive cryptographically signed success signals from both trusted domains for a common operation identifier (case_id, PID_U, PID_ext) and only marks a combined success event (E_success) in the event store (ES) and allows the SUCCESS_CONFIRMED state if the success signals are consistent with respect to signature, time window (Δt), communication channel and negative lists (E_neg). [22] System according to any one of the preceding claims, characterized by, that the verification chain and state machine depicted in blocks 1 to 4 are designed in the form of a domain-independent, reusable technical framework which can be used unchanged in different technical deployment scenarios, in particular for the release of payments or remuneration, the technical activation of services, API access or configuration changes, whereby adjustments are essentially limited to the parameterization of boundary conditions, event types, involved trust domains and interfaces, without having to change the function-determining core logic of the four-block structure or the gatekeeper. [23] System according to any one of the preceding claims, characterized by, that when an external sales or cooperation domain (C_ext) transmits an order to an external supplier or product provider domain (EXT_PROVIDER), it also transmits a process reference managed by the gatekeeper system, which includes at least the process identifier (case_id) and / or a pseudonymous identifier (PID_ext). [24] System according to claim 23, characterized by , that the external provider or product supplier domain (EXT_PROVIDER) stores the transaction reference and transmits it along with the success and / or settlement signal to the gatekeeper system, so that the gatekeeper system can uniquely assign the signal to the transaction in question. [25] System according to claim 23 or 24, characterized by, that the Process Service (PS) sets a summarized success event (E_success) and the state SUCCESS_CONFIRMED only if success signals with identical process reference have been received from both the external sales or cooperation domain (C_ext) and the external supplier or product vendor domain (EXT_PROVIDER) and these success signals have additionally passed the checks described in the preceding claims regarding signature, time window (Δt), communication channel and negative events (E_neg). [26] System according to any one of the preceding claims, characterized by , that the Gatekeeper system (GK) is designed as a neutral instance that is not assigned to any of the trust domains (U, C_ext, EXT_PROVIDER), but is operated technically separately from them and exclusively provides testing, verification and release logic for the events exchanged between the trust domains. [27] System according to any one of the preceding claims, characterized bythat the state engine of the Process Service (PS) divides the verification chain into four blocks, namely a consent and identity block (Block 1) with recording of the consent event (E_C), the out-of-band event (E_oob) and the operation identifier (case_id, PID_U, PID_ext), an event and multi-source acknowledgment block (Block 2) with append-only logging in the event store (ES), multi-source acknowledgment (E_success) and consideration of negative events (E_neg), a revision and time anchor block (Block 3) with revision ledger (AL), hash chain (prev_hash) and external anchor events (E_anchor, ledger_anchor) and a wait time and target event block (Block 4) with timer (TI), monitoring of negative events (E_neg) and verification of a verified target event (E_settlement), and that transitions to the release-ready state (PAYABLE) will only be accepted if all four blocks have been passed without objection. [28] System according to any one of the preceding claims, characterized by , that the gatekeeper system (GK) is configured to mark a settlement for a transaction as expected based on a success event (E_success) confirmed by multi-source verification, to check incoming settlement messages as target events (E_settlement) from at least one sales or settlement domain against the evidence series from event storage (ES), revision ledger (AL) and external time anchor (ledger_anchor), and, if a consistent settlement message is not received within a configured time window, to transfer the transaction to a payout_overdue state, whereby the gatekeeper system (GK) itself does not execute any payments and does not manage any payment flows, but technically monitors and audit-proofs the settlement and settlement status across multiple trust domains. [29] System according to any one of the preceding claims, characterized by, that the data exchange between the participating trust domains (U, C_ext, EXT_PROVIDER) is limited to a minimum required data set (D_min), which in particular includes a case identifier (case_id) and / or pseudonymous identifiers (PID_U, PID_ext) as well as only those characteristics that are technically necessary for carrying out the audit chain, whereby clear data on persons or contracts remain in the respective trust domains and correlations across domains are carried out exclusively via the pseudonymous identifiers and the case identifier. [30] System according to any one of the preceding claims, characterized by, that the Access Control Service (ACS) is configured to check license and status information of intermediary parties before accepting events, especially consultation and completion messages, to issue time-limited tokens (T_exp) with role and attribute information for access to the Gatekeeper System (GK) only if valid license and status proof is provided, and to reject incoming events or mark them as negative events (E_neg) if the underlying license or status checks are negative. [31] System according to any one of the preceding claims, characterized by, that an AI-supported risk analysis module is provided which determines a risk score for a process based on event data, negative events (E_neg) and context information stored in the event log (ES) and revision ledger (AL), and that the Process Service (PS) is configured so that a transition to the releaseable state (PAYABLE) is only permitted if, in addition to the gate conditions fulfilled in blocks 1 to 4, a configured risk threshold is not exceeded.

Images