Durable delivery
The SDK queue and redelivery mechanism track records through receipts from the central service.
Architecture
Recording and verification within your institution
Sigillum Finans is designed for an independent installation on each institution’s own servers. The API, portal, evidence store and separate witness operate within the institutional network, with applications sharing the recording infrastructure.
01 / Institutional deployment
One portal, an evidence store and a separate witness
Institutional applications and shared services send records to Sigillum Finans through SDKs or the collector. The API and portal run as one service, with transaction records held in the institution’s PostgreSQL evidence store.
The witness operates inside the institutional network with separate records and keys. The customer deployment architecture separates its administration, storage and failure domain from the main system. Institutional identity, archive, timestamp and notification services connect to this environment.
ARCHITECTURE VIEW / 01
Within your institution, with separate operating boundaries
From application records to evidence review. The portal and API share an installation; the witness operates in a separate area with its own storage and keys.
THE INSTITUTION’S SERVERS AND NETWORK
APPLICATION LAYER
SDK integration
.NET · Java · Python · Node.js
Transaction, HTTP and message records
TELEMETRY LAYER
OpenTelemetry
OTLP / HTTP JSON
Collector and GenAI mapping
SIGILLUM FİNANS
API and institution portal
Ingestion, coverage and review
Authorized institution access
EVIDENCE STORE
PostgreSQL
Records, signatures and relationships
Encrypted transaction content
SEPARATE OPERATING AREA
Witness service
Recording signed receipts
A separate source for reconciliation
OWNED BY THE WITNESS
Journal and keys
Separate durable storage
Separate signing keys
01
Record delivery
The SDK and collector deliver records to Sigillum through a local durable queue.
02
Witness reconciliation
Signed acceptance receipts and chain information are sent to the witness. Signed witness responses support reconciliation.
03
Institutional control
Production deployment separates the witness’s storage, keys, administrative authority and failure domain.
02 / Record lifecycle
From record creation to evidence review
The SDK places service records in a durable delivery queue. The central service persists records received through authenticated service connections and issues signed receipts. Records are appended to the transaction chain and compared with a separate witness record.
The portal brings together transaction content, record provenance, scope status and verification results. Evidence packages and witness excerpts can be exported for offline verification, while retention policies and archive operations manage the later stages of the record lifecycle.
Signed records
Receipts and chain links support integrity checks; corrections are appended as new records.
Portable evidence
Evidence packages, witness excerpts and offline tools allow the same records to be verified in different review environments.
ARCHITECTURE VIEW / 04
From recording to independent verification
Transaction records are persisted, protected with signed receipts and compared with separate witness records. Packages prepared for review are checked with offline verification tools.
EVIDENCE LIFECYCLE / WITHIN THE INSTITUTION
01 / INGESTION
Linked record
Identity, sequence and content checks
Record provenance and transaction context
02 / PERSISTENCE
Signed acceptance receipt
Durable record and encrypted content
Chain link to the preceding record
03 / REVIEW
Institution portal
Transaction, coverage and verification
Case file and record history
SEPARATE WITNESS / RECONCILIATION
Separate witness record
Signed receipts and chain information
Comparison between records
04 / PACKAGE
Portable evidence
Evidence package + witness slice
Signatures and chain links
05 / VERIFICATION
Offline verification
Public keys obtained through a
separate trusted channel
01
Retention and legal hold
Institutional retention and approval policies govern handling; legal holds and disposal actions are recorded.
02
Archiving and time
Internal S3-compatible archiving, RFC 3161 timestamps and long-term preservation workflows can be configured.
03
Reviewable verification
Evidence and witness signatures are verified against separate trusted keys; verification results accompany the review.
03 / Separate witness
Independent comparison with the primary record
The witness retains the API’s signed acceptance receipts and chain information in its own durable journal. Signed witness responses are compared with the primary evidence store, and chain differences can be examined in the reconciliation view.
In production, the witness’s separate keys, durable storage, administrative authority and failure domain are defined within the institution’s operating model. Custody checkpoints provide additional preservation and later comparison of witness history.
04 / Institutional identity
Single sign-on and role-based actions
The institution’s OIDC or SAML identity provider can be used for single sign-on. TOTP and WebAuthn second factors, renewed authentication and dual approval for selected operations are available within the access policy.
Institutional identity comes from an authenticated session or service connection. Authorization is institution-wide: authorized teams see the institution’s applications, and roles determine the actions they can perform. Session and access activity is retained in audit records.
05 / Shared services
Reuse integrations across applications
API gateways, AI, scoring and decision services shared within the same institution and environment are integrated once at their common point. New applications define entry points and recording scopes that use these connections.
Signed transaction context links service activity across supported HTTP and messaging paths. W3C trace context carries the related trace information; internal routes and context propagation are defined in configuration.
06 / Institutional infrastructure
Storage, key and notification services
Sigillum Finans connects to institutional infrastructure through S3-compatible archives, RFC 3161 timestamps, certificate validation, SMTP and syslog. File-based storage and HashiCorp Vault Transit are available as key providers.
TLS, internal DNS, network policies, provider placement, backups and capacity targets are defined in the institution’s deployment plan. Production acceptance validates how these components work together in the target environment.
PRODUCT INFORMATION
Frequently asked questions
Where does the installation run?
Each customer institution runs an independent Sigillum Finans installation on its own servers. The portal, API, PostgreSQL evidence store, witness and connected institutional services are placed within the institution’s network boundary.
What does the witness do?
The witness retains signed acceptance receipts in a separate durable journal. Comparisons with the primary evidence store support examination of differences in the record chain. Witness results are available in the shared portal’s reconciliation and evidence views.
How are the institution’s applications managed?
Applications use the same portal and evidence infrastructure. Service identities belong to an institution and environment, while entry points and recording scopes define applications. Roles determine the actions available to the institution’s authorized users.
How does offline verification work?
The verifier examines an evidence package and witness excerpt against public keys trusted through an independent channel. Signature, content-hash and chain checks run locally, with separate results in the verification output.