Integration & Compliance Framework

The HilmarCorp Retail offering consists of publishing, via API, an exposure signal to the client in a standardized format. The signal is intended for use by the client to control execution on instruments available on the selected platform, notably perpetual contracts. The service is intended for users capable of assessing risks and implementing appropriate controls. This document exclusively describes this Retail scope. The HilmarCorp Institutional offering is a separate product, operated with separate terms and documentation.

The client remains fully responsible for the decision to use the signal, its interpretation, execution of operations, asset custody, and compliance with their own regulatory, tax, or contractual obligations. HilmarCorp does not participate in the custody, execution, or management of the client’s assets.

No mandate, delegation, or transfer of responsibility is granted to HilmarCorp. The reference local connector runs exclusively on the client’s infrastructure, with no transmission of secrets, credentials, or access to HilmarCorp.

The operational flow provides that the client queries the HilmarCorp API to retrieve the exposure signal. The local connector, provided as a reference, enables technical integration, but its configuration, adaptation, and maintenance are the sole responsibility of the client. Order execution, asset management, and logging are performed directly by the client via their own account(s) on the selected exchange platforms.

When execution is performed on derivative instruments (including perpetual contracts), the local connector is not intended to define margin and leverage parameters for the platform; it is the client’s responsibility to configure, control, and ensure their appropriateness.

Secrets for exchange platform access (API keys, access rights) never transit through HilmarCorp and must be stored and managed by the client using appropriate means (secret vault, environment variables, etc.). The client is responsible for limiting permissions to operational needs and implementing appropriate governance.

The client must implement appropriate risk management measures, including setting limits, enabling an emergency stop (kill switch), and continuous supervision of connector operation and execution flows. The responsibility for monitoring, control, and compliance remains entirely with the client.

Publication consists of making available an exposure signal, understood as a technical indicator of the net portfolio exposure target, expressed as a fraction of the notional capital allocated by the client. By design, the signal value is bounded in the interval [-1, 1] and does not encode any leverage parameter. Margin, leverage, liquidation parameters, and more generally, execution modalities are the sole responsibility of the client and subject to the rules of the selected platform. Each publication is timestamped in UTC and comes with a documented validity window. In case of non-publication, the expected client-side behavior (maintain, neutralize, fallback) is defined and documented by the client. This signal does not constitute an execution instruction or personalized recommendation. Reading and interpretation parameters (bounds, neutralization, calendar, thresholds) are specified in the Data Contract applicable to the service version.

The data contract governs the structure, format, versioning, and publication governance: each signal has a unique identifier and version metadata. Any substantial schema change follows a formal process including advance notice, documentation, and, if applicable, a migration plan.

Message integrity relies on a cryptographic fingerprint (manifest/hash) and, depending on the integration, may include a source authentication mechanism (signature, mTLS, or equivalent). These modalities are specified in the technical documentation and must be verified by the client.

API access requires authentication with dedicated credentials, under the principle of least privilege. Authorizations are restricted to the strictly necessary scope and are subject to rotation and revocation procedures. Communications are encrypted in transit (TLS).

Access and operational events are logged for operational and traceability purposes. Security measures include access control, segmentation, allowlisting, and, where applicable, use of mTLS. HilmarCorp cannot access client trading accounts or secrets.

The local connector is designed to minimize secret exposure, favoring reading from a secure vault, avoiding logging of keys, and restricting permissions to the strict minimum. The client is responsible for configuring access rights and implementing additional protections (IP restrictions, strong authentication) on exchange platforms.

Vulnerability management is based on a proportional approach, including dependency monitoring, patching, and secure development practices to reduce attack surface. Summaries or results of technical controls can be provided on request, without guarantee of completeness.

Using the service does not require transmission of the client’s trading data or access to their exchange accounts. The API delivers an exposure target and purely technical metadata. HilmarCorp does not collect or hold exchange platform access keys and does not hold any assets on behalf of the client. The only data collected relates to subscription management (account, billing data) and technical logs necessary to provide the service.

Retention periods, deletion rules, and data purge procedures are defined and communicated. Upon request or at the end of the contractual relationship, account data and logs are deleted according to the applicable policy, with traceability where required. If personal data is processed incidentally (support, contacts, technical logs), security measures and responsibilities are specified in a data processing agreement (DPA) if required by law.

The setup follows a formalized operational approach: supervision of API availability, latency, errors, and schema anomalies, with alerts based on pre-established thresholds. Recovery procedures are documented and rely on client-side idempotency, controlled reconnection attempts, and handling of temporary publication absences.

The client is responsible for defining and maintaining an appropriate fallback policy (e.g., retaining last valid value, neutralizing exposure, or other chosen continuity rule), as well as local supervision and logging arrangements. In the event of a significant incident, HilmarCorp may communicate information regarding the nature, impact, and resolution of the incident, in accordance with applicable contractual and regulatory obligations.

Incident management is based on internal classification, an escalation runbook, and documented resolution procedures. Where relevant, a post-incident report and corrective action tracking are provided. This setup aims to be compatible with governance requirements in the financial sector, without prejudice to the client’s own obligations.

The product documentation aims to enable a precise understanding of the service’s characteristics: signal conventions, interpretation assumptions, limits, and associated risks. Any historical performance elements provided are presented with their assumptions (data, fees, slippage, constraints, periods), their limitations (overfitting risk, selection bias, non-reproducible market conditions), and an explicit statement that no future performance is guaranteed. Information is provided with a view to transparency and risk awareness.

The robustness protocol includes out-of-sample validations, sensitivity tests (fees, frictions, delays), regime stability analyses, and degradation controls. The list of tests and reports provided is defined per version, ensuring traceability and reproducibility.

This section describes the methodological framework applied to any communication of historical results. It is not intended to highlight performance, but to specify a standard of evidence: traceability of assumptions, reproducibility of calculations, and comparability of results. Results (if published) are presented with their assumptions, limitations, and parameters.

The core of the setup is simple: out-of-sample (OOS) evaluation is performed on a strictly post-training, post-model-selection time segment. Model selection is admissible only on validation, never on test. Transformations applied to OOS observations replicate those in training, with no ad hoc conventions.

OOS evaluation. Evaluation consists of a complete rollout of the policy on the test segment, with systematic export of a step-by-step trace (timestamp, exposure, equity, drawdown, costs if available, technical events). The philosophy is operational: an aggregate metric must be reconstructible from elementary events, without manual interpretation.

Comparison is performed against temporally aligned references. A Buy & Hold is reconstructed on the same timestamps, and a vol-target variant may be produced to compare volatility-matched profiles, without changing the nature of the benchmark. Assumptions (fees, frictions, calendar, calculation conventions) are made explicit in the report.

Robustness. Robustness is treated as a methodological property: the conclusion must not depend on a single period, a single seed, or a single friction assumption. The protocol thus aims to produce distributions of metrics (medians and quantiles), rather than a "best run".

Concretely, robustness combines a temporal walk-forward (repetition over multiple windows), multi-seed runs (stochastic variability), uncertainty estimation by block resampling (temporal dependence), and operational stress tests (cost sensitivity and extraction of "worst case" windows). Where multiple trials are performed, their number is documented and results are presented as robust summaries (quantiles) to limit selection bias.

For the Retail offering, HilmarCorp acts solely as a technology provider, publishing technical information and standardized integration documentation. The service does not include asset custody, order execution, order transmission, portfolio management, receipt of instructions, or account/position keeping. The service does not perform any suitability or appropriateness assessment, nor any customization of the transmitted signal.

When the client uses derivative instruments, including perpetual contracts, these may involve leverage and a risk of rapid loss, notably in the event of margin calls or liquidation. The client remains solely responsible for verifying their eligibility, applicable restrictions (regulatory and platform), and the compliance of using the service with the relevant legal framework.

A perpetual contract is a derivative instrument with no expiry, generally linked to a funding mechanism, and may be traded on margin.

Perpetual contracts may involve funding payments that can affect performance and risk.

According to platform rules and market conditions, losses may be rapid and, in some cases, exceed the initial collateral allocated.

The legal qualification of the service depends on the concrete modalities of use and the context of the relevant jurisdiction. The client remains solely responsible for the compliance of their operations, adherence to applicable regulations (including tax, AML/CFT, and platform-specific restrictions), supervision of execution, asset custody management, and implementation of appropriate internal controls.

The client is responsible for verifying the suitability of instruments used, compliance of service use with their own framework, exchange platform rules, and all applicable legal and regulatory obligations. HilmarCorp does not participate in instrument selection, execution, platform choice, or implementation of the client’s controls. The client is encouraged to seek their own advice.

Standard integration involves creating API access, retrieving the up-to-date Data Contract, installing the reference local connector, configuring critical parameters (thresholds, limits, calendar, behavior in case of non-publication), managing access secrets in a secure vault, conducting a controlled test (simulation or dry-run mode), and then moving to live execution under enhanced supervision. It is recommended to apply prudent limits during initial phases and make progressive adjustments based on operational experience.

Support is limited to technical integration questions (format, versioning, idempotency, error handling). HilmarCorp never intervenes on the client’s exchange account, nor in decision-making or risk management. All execution, management, and control decisions rest exclusively with the client.

Important notice. Digital assets carry a significant risk of capital loss. No return, result, or performance is guaranteed. The information provided in this documentation is general and technical in nature; it does not constitute personalized advice, an investment recommendation, or a solicitation to execute transactions. Use of the signal on leveraged instruments (including perpetual contracts) may amplify losses and expose to liquidation; clients should ensure these instruments are appropriate for their situation and compliance framework. According to platform rules and market conditions, losses may be rapid and, in some cases, exceed the initial collateral allocated.

Non-reliance. This document should not be interpreted as contractual documentation, an execution guarantee, or a commitment to availability. The client should not rely on it as a substitute for their own due diligence, internal controls, or independent professional advice. It is expressly recommended to seek independent legal, tax, and regulatory advice before any use of the service.

Responsibilities. The client remains solely responsible for interpreting the signal, decision-making, controls, execution, asset custody, and compliance with applicable regulations and exchange platform terms. HilmarCorp does not receive or store exchange platform access keys, does not access any trading account, and does not execute any orders.