DBIS HYBX Sidecar Boundary Matrix

Last updated: 2026-03-28
Purpose: Define the current boundary, role, and likely RTGS relevance of the HYBX sidecar repositories currently available in the local workspace. This is a repo-backed companion to the RTGS E2E requirements matrix.

Interpretation

Available locally means the repository exists in /home/intlc/projects/HYBX_Sidecars.
RTGS relevance means whether the sidecar is likely part of the initial production RTGS slice, not whether it is interesting or strategically useful.
Boundary frozen means the sidecar has a sufficiently clear place in the RTGS architecture to be used in implementation planning.

Matrix

Sidecar	Local repo state	Core purpose	Key internal modules / evidence	RTGS relevance	Boundary frozen?	Notes
`mifos-fineract-sidecar`	Available locally	Compliance and settlement sidecar for Mifos/Fineract	`scsm-api`, `scsm-gateway`, `scsm-compliance`, `scsm-posting`, `scsm-fineract`, `scsm-settlement`, `scsm-reconciliation`, `scsm-audit`, `scsm-events`, `scsm-observability`, `scsm-app`	High	Partial	This is the strongest candidate for the canonical OMNL/HYBX RTGS sidecar because it already models compliance, posting, settlement, reconciliation, audit, and Fineract integration.
`mt103-hardcopy-sidecar`	Available locally	MT-103 hardcopy ingest and deposit-envelope correlation	Go service with document/deposit/payload/submit flows	Medium	Partial	Useful for evidence/audit and documentary payment flows, but not necessarily a mandatory first-slice RTGS core dependency.
`off-ledger-2-on-ledger-sidecar`	Available locally	XAU-collateralized off-ledger to on-ledger conversion	Collateral registry, orchestrator, ledger adapter, API plan	High	Partial	Strong candidate for the bridge between off-ledger payment events and on-ledger liquidity/settlement on Chain 138.
`securitization-engine-sidecar`	Available locally	Regulatory accounting and securitization engine	Asset classification, risk/capital, accounting, securitization, reporting	Medium	Partial	Important for structured products, capital treatment, and reporting, but likely adjacent to core RTGS rather than in the narrowest first production slice.
`card-networks-sidecar`	Available locally	Card auth, clearing, settlement, disputes	`cardnet-auth`, `cardnet-clearing`, `cardnet-fineract`, `cardnet-settlement`, `cardnet-reconciliation`, `cardnet-posting`, `cardnet-audit`	Medium	Partial	Highly relevant if card-network settlement is part of the DBIS/HYBX program; otherwise a later rail-specific extension.
`server-funds-sidecar`	Available locally	Multi-rail transfers and settlement events	`funds-api`, `funds-transfers`, `funds-settlement`, `funds-reconciliation`, `funds-posting`, `funds-fineract`	High	Partial	Strong candidate for server-to-server treasury/funds movement and may be central if the RTGS program uses server-funds orchestration.
`securities-sidecar`	Available locally	Securities instruction, settlement, and reconciliation	`securities-instruments`, `securities-instructions`, `securities-settlement`, `securities-reconciliation`, `securities-posting`	Low/Medium	Planned	More naturally a securities-settlement extension than a mandatory first RTGS slice.
`flash-loan-xau-sidecar`	Available locally	Atomic XAU / LiXAU flash-loan flows	`xau-atomic`, `xau-settlement`, `xau-reconciliation`, `xau-posting`	Low/Medium	Planned	Valuable for specialized liquidity/XAU flows, but not required for the narrowest RTGS baseline.

Recommended first production slice

For the narrowest credible RTGS implementation, the strongest initial sidecar candidates are:

mifos-fineract-sidecar
server-funds-sidecar
off-ledger-2-on-ledger-sidecar

Those three cover the most direct path across:

Fineract integration
compliance / posting / settlement / reconciliation
treasury/server-funds orchestration
off-ledger to on-ledger conversion

Recommended later-phase sidecars

mt103-hardcopy-sidecar
card-networks-sidecar
securitization-engine-sidecar
securities-sidecar
flash-loan-xau-sidecar

These should be added only when the RTGS program confirms those rails or reporting models are actually in scope.

Boundary decisions still needed

Which sidecar owns the canonical settlement orchestration record?
Which sidecar owns final posting responsibility versus suggested-entry generation?
Which sidecar emits the canonical event consumed by FireFly or on-chain settlement?
Which sidecar is system-of-record versus adapter versus evidence generator?

5.1 KiB Raw Permalink Blame History