Institutional integration framework & compliance

HilmarCorp delivers, on a daily basis, a non-binary exposure target on a crypto sleeve defined with the client. The service is structured as an exposure overlay: HilmarCorp operates the engine (signal production, rebalancing logic, consistency and publication controls), and provides all elements necessary for monitoring, traceability and audit, without intervening in asset custody or execution.

The client retains full operational sovereignty. Custody, OMS/EMS, execution, and all internal processes (limits, compliance, validations, supervision) remain on the client side. The client defines the investable universe, liquidity requirements, execution venues, and constraints specific to their setup. The overlay is then calibrated to operate within this scope, according to delivery and traceability conventions aligned with institutional standards.

For pilots, HilmarCorp acts as a technology provider integrated into the client’s environment. Final decision, supervision, and execution responsibility remain with the client, including through override mechanisms, limits, validations, and internal controls.

Delivery modes are defined during pilot scoping, according to your operational, archiving, reconciliation and control requirements. Depending on the target architecture, consumption may occur via API (pull), batch delivery through a data exchange (SFTP/S3 or equivalent), or publication on an event bus (Kafka or equivalent).

The data contract is versioned and conservative: UTC timestamps, stable schemas, documented compatibility rules, idempotency, and explicitly defined recovery procedures. Each publication carries a unique identifier, enabling reconciliation across delivery, ingestion, internal transformations and reporting. Any significant change is subject to change governance agreed with your teams (versioning, advance notice, migration plan, and, where relevant, rollback mechanisms).

Publication integrity relies on fingerprint controls (manifest/hash) and, where required, mechanisms to attest to the authenticity of the source. Depending on delivery mode, payloads may be signed or authenticated (application signature, PGP, client certificates via mTLS or equivalent mechanisms), enabling client-side verification of the origin and integrity of received data.

Where the client’s data chain is based on an industry standard such as Penelope XML, HilmarCorp can, as part of the pilot, provide a mapping and export adapter, including target schema, validation rules and test datasets for acceptance, in order to align the delivery format with existing IT conventions.

Exposure conventions are fixed at pilot scoping and formalized in a “Data Contract” annex. This annex specifies, in particular, the signal semantics, units, bounds, granularity, multi-asset conventions, publication calendar, as well as the interpretative assumptions required for order transformation, which remains the exclusive responsibility of the client.

By design, exchanges do not require client‑identifying data: they concern exposure signals and integration metadata. Data classification (internal/confidential), hosting location (EU/EEA where required), retention policy, and minimization principles are defined at scoping. Retention durations, purge rules and deletion procedures are also scoped and documented, with traceability of deletion operations where applicable.

By design, the overlay does not require personal data. If, exceptionally, personal data must be processed (e.g., operational contacts or certain technical logs), respective roles (controller/processor), legal basis, security measures, and, where applicable, a processing agreement (DPA) are formalized in accordance with GDPR.

{
  "publication_id": "pub_2026-01-31_00-00-00Z",
  "ts_utc": "2026-01-31T00:00:00Z",
  "universe_id": "client_universe_v1",
  "exposure_target": { "type": "portfolio_exposure", "value": 0.35 },
  "engine": { "engine_version": "0.1.0", "schema_version": "1", "environment": "pilot" },
  "integrity": { "manifest_sha256": "..." }
}

Auditability is designed as a property of the system. Each publication is linked to a stable identifier, a versioned schema, and an engine version. Fingerprints (manifest/hash) enable ex post verification of the integrity of transmitted payloads and detection of discrepancies between delivery, ingestion and consumption.

Depending on client requirements, audit artifacts (publications, manifests, logs) may be retained in conditions that make any alteration detectable ex post, notably via sealing mechanisms (hash chain) or immutable storage (WORM or equivalent), irrespective of the technical solution chosen.

End-to-end traceability is enforced: publication, receipt, any transformations, controls and exceptions. The objective is to enable robust reconstruction of key events over a defined retention horizon, for the benefit of internal control, governance reviews and, where relevant, audit.

The service is designed according to the principle of least privilege. Access is managed through dedicated credentials and keys, with rotation/revocation, environment separation, and action logging. Exchanges are encrypted in transit (TLS), and the delivered data scope is minimized and controlled.

No secrets are exposed on the public front. Client-side integration is performed via environment variables or secret vaults, depending on the target architecture. Network posture (segmentation, allowlisting, mTLS where required) and key management practices (KMS/HSM or equivalent), as well as at-rest encryption of relevant artifacts, are defined at scoping and documented in the pilot’s security dossier. Log retention policies (retention, timestamping, integrity) and, where relevant, audit artifact archiving, are aligned with client requirements.

The pilot scope is subject to an appropriately scaled application security process: patch tracking, dependency management, periodic access reviews and logging of sensitive operations. Where required, assurance elements (questionnaires, scan/test summaries) may be shared as part of due diligence.

Operational access and deployment rights are separated and logged; interventions in pilot and, if applicable, production environments follow an approval and traceability process, enabling subsequent review.

The system is designed for realistic operations: supervision of delivery completeness, latency, errors, and schema anomalies, with alerting thresholds defined at scoping. Recovery procedures are documented from the pilot’s outset.

For API, recovery relies on idempotent requests and controlled retry/backoff policies. For batch, republication is managed via manifests and publication identifiers. For streaming, replay mechanisms rely on retention policy and offsets, within a documented framework.

Operational commitments for the pilot are formalized in a runbook: daily publication window (cut-off), latency tolerance, planned maintenance rules, escalation channels, incident classification, and respective responsibilities. Incident notification (timelines, recipients, minimum content), defined at scoping by criticality, is accompanied, where appropriate, by a post-incident report and follow-up of corrective actions.

In case of non-publication, schema anomaly or incomplete data, the expected behavior is defined in advance (maintain last valid signal, neutralization, or agreed fallback policy). A client-side freeze/override mechanism is provided to ensure operational control in all circumstances.

Business continuity is addressed with measures proportionate to the pilot’s scope: backups, restoration procedures, contact points and recovery arrangements, to guarantee continuity of publication or activation of an agreed degraded mode.

The client remains responsible for its regulatory and compliance framework. HilmarCorp provides a technical component (exposure delivery and traceability) integrated into the client system, and adapts due diligence documentation to the defined scope.

Where the scope includes derivative-type instruments, the institutional reference framework generally relates to the applicable financial instruments regime (notably MiFID II) and, depending on the client’s setup, to reporting or clearing obligations (e.g., EMIR). The legal qualification of the service is not based on formulaic statements: it depends on the concrete integration arrangements, level of customization, governance, and the degree of control/override held by the client. In pilots, HilmarCorp acts as a technology provider; final decision, supervision, and execution remain with the client.

Schema and engine changes are governed: semantic versioning, reviews, approvals, release traceability, backward compatibility, migration plan and rollback mechanisms where necessary. Role separation and deployment rights are managed in accordance with standards expected in regulated environments.

The pilot includes proportionate “model risk” governance: stability indicators, anomaly controls, and disabling conditions in case of non-compliant behavior. The client-side freeze/override capability is a central element of the control framework.

Due diligence documentation covers, in particular, incident management, continuity, security, access control, retention, data protection, subcontractors, audit arrangements, and allocation of responsibilities. Detailed documents (security pack, privacy, incident response, change management, third-party risk, runbook and pilot operational commitments) are provided once the scope is defined.

Where pricing includes a variable component, it is capped (ceilings, bounds, transparency) to limit churn incentives. HilmarCorp does not intervene in OMS/EMS, execution venue selection or execution; the client retains controls, limits and validations. In practice, fixed pricing is preferred at the pilot stage, with an optional, contractually-capped variable component.

The list of providers and critical dependencies (cloud, data sources, observability) and associated responsibilities are communicated at scoping, as well as the subcontractor change policy and notification procedures.

Confidentiality arrangements (NDA), responsibilities, audit rights on the pilot scope and intellectual property are contractually defined. The client retains ownership of its data and execution decisions; HilmarCorp retains ownership of its engine and software artifacts, subject to agreed commitments for pilot operation.

Responsibilities and non-reliance. Exposure signals provided in the pilot context are technical information intended for integration into the client’s system. The client remains solely responsible for interpretation, controls, decision and execution. Responsibility, limitation and non-reliance conditions are contractually defined at pilot scoping.

Any mention of the client, its name, logo or the pilot in any external communication is subject to prior written agreement.

An institutional pilot begins with precise scoping: universe and constraints, timeline, operating modalities (paper, advisory overlay, or phased implementation), control points, responsibilities and success criteria. Scoping formalizes delivery and supervision conventions, change governance, release validation rules, escalation procedures and audit arrangements. The timeline distinguishes the scoping/contractualization phase and, where relevant, a subsequent operational execution phase, triggered after achievement of stabilization and validation milestones defined with the client.

Deliverables are integration- and control-oriented: delivery conventions, schemas and mappings, “Data Contract” annex, operational runbook, supervision requirements and pilot report. Performance and robustness protocols (tests, stability, out-of-sample validation) are communicated when the model is stabilized, in a framework compatible with client governance and compliance requirements.