> For the complete documentation index, see [llms.txt](https://host2host.onibonje.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://host2host.onibonje.com/readme.md).

# Heirs H2H Integration Platform

A standardized **Host-to-Host (H2H)** integration platform for multi-country corporate banking, built on **Apache Camel**, **composable Java modules**, and **database-driven configuration** to enable low-code operations.

## Architecture Status

**ARCHITECTURE COMPLETE — 48 documents — READY FOR IMPLEMENTATION**

See [Architecture Sign-Off](/docs/42-architecture-sign-off.md) for the full gate checklist.\
Program budget and staffing: [44 Program Cost and Staffing](/docs/44-program-cost-and-staffing.md).\
**Bid proposal:** [49 Bid Proposal](/docs/49-bid-proposal.md) — USD 2.0M **floor** / 24 months, extension framework for scale-up

## Documentation

Full index: [**docs/README.md**](/docs.md) (48 documents)

| Section            | Documents     | Description                                                                        |
| ------------------ | ------------- | ---------------------------------------------------------------------------------- |
| Foundation         | 01–12         | Architecture, stack, config, admin, security, roadmap                              |
| Design             | 13            | Design patterns catalog                                                            |
| Platform libraries | 14–21         | File, security, observability, context, extensibility, events                      |
| Domain             | 23–31, 43     | Finacle, CBS API, transforms, ACK, recon, treasury, MQ, data model, schema, errors |
| Operations & API   | 32–41         | Performance, DevSecOps, ops, testing, APIs, portal, topology, workflows, training  |
| Validation         | 22, 42, 44–48 | Use cases, sign-off, cost, DB portability, events, gateway, notifications          |

## Design Principles

1. **Standardize across 20+ markets** — country differences via configuration.
2. **Composable capabilities** — versioned JAR modules, thin runtime.
3. **Configuration over code** — partner behavior in the relational config store (vendor-agnostic RDBMS).
4. **Low-code for operations** — publish without redeploy.
5. **Event-driven extensions** — database-driven event channels (`event_def`) + runtime subscriptions.
6. **Broker-delayed scheduling** — no in-process cron; jobs survive outages.
7. **CBS base library** — `h2h-core-banking-api`; Finacle is one provider type, extensible to other core banking systems.
8. **Deployment-agnostic** — same JARs on Kubernetes, standalone JVM, or legacy app server (WAR).
9. **Universal library extensibility** — one CustomizationProfile, all libraries.
10. **Audit everything** — immutable transaction and config trails.

## Quick Reference

```
Client (ERP / Fintech / Corporate)
        │
        ▼
H2H Gateway (SFTP / HTTP / WebSocket / MQ)
        │
        ▼
Apache Camel Runtime (composable JARs)
        │
        ├── H2hContext + CustomizationProfile
        ├── Transform → Canonical → Finacle
        └── Events → Webhooks / Subscriptions
        │
        ▼
Finacle (FCJ / FCUBS) — ACK/NACK → Partner
```

## Next Step

Implementation per [Implementation Roadmap](/docs/10-implementation-roadmap.md) — begin Phase 1 foundation modules.

## Issued By

Heirs Technologies — Group-Wide Host-to-Host Integration Platform


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://host2host.onibonje.com/readme.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.