The self-service entry point for external law firms, compliance advisors, audit firms, and RegTech houses that want to bring their own regulatory gates into the immo.quick infrastructure, without modifying the platform itself.
Until now, every gate was hardcoded into the platform. Every new regulatory requirement, every new sector, every new jurisdiction required an extension by the platform team. That does not scale.
The GATE-SDK reverses this relationship. The platform provides a single, stateless, forensically isolated execution runner, the genericGateRunner. A third party simply submits a declarative configuration, no code, describing which checks its gate should run. The runner handles the rest.
The portal is the interface through which these configurations are registered, signed, published to the catalogue, and subsequently executed.
A law firm with deep expertise in a specific local regulation previously had two unsatisfying paths: build its own software, expensive, error-prone, without forensic integrity, without a Merkle chain, without a TSA anchor. Or ask the platform team to implement a new gate, which takes weeks, blocks the roadmap, and costs the firm authorship over its own expertise.
The GATE-SDK solution: the firm describes its gate as a signed configuration and submits it through the portal. From that moment on, any authorised user can execute the gate, through the same runner, with the same forensic guarantees. The growth of the gate library is thereby decoupled from the platform's own development speed.
Regulated companies themselves do not use the portal to register, but to execute: they search the catalogue for the matching gate and receive a forensically sealed receipt carrying the authorship of the registering firm.
| Field | Meaning |
|---|---|
| gate_id | unique identifier, must start with EXT_ |
| author_did | the author's institutional DID |
| author_signature | cryptographic signature over the config hash |
| config_hash | SHA-256 over the canonical configuration |
| status | published · suspended · revoked |
| invocation_count | execution counter |
Three components carry the system. The GateCatalogEntry entity stores every registered third-party gate entry. The registerThirdPartyGate function computes the canonical config hash, verifies the author's HMAC-SHA256 signature, prevents collisions, and stores the entry, admin-protected. The invokeCatalogGate function loads a configuration from the catalogue and delegates to the same genericGateRunner that also runs every platform gate.
The author computes the canonical config string, its SHA-256 hash, and signs that hash via HMAC-SHA256 using their own DID as the key. If the signature does not match the hash at registration, the submission is rejected fail-closed. On every execution, authorship travels into the receipt.
Müller & Partner, based in Luxembourg, has expertise in local AML law for investment funds and private-equity structures and wants to offer it as a gate.
This receipt holds up before the CSSF: it proves when the check ran with which configuration, and that this configuration was cryptographically signed by Müller & Partner.
Not the SystemWriter. The SystemWriter generates text, documentation, articles, based on system data. The GATE-SDK Portal does not generate text, it generates forensically sealed check routines.
Not identical to platform gates. Platform gates such as gateDORA or gateFATF are hardcoded, their rule version lives in the backend code. GATE-SDK gates are declaratively configured, signed by third parties, stored in the database, but use the same runner.
The GateCatalogEntry entity is the table, the portal is the interface. The entity stores, the portal populates and queries.