What BankReconciliation does

BankReconciliation is a multi-tenant platform that takes two inputs - payment registries and nostro account statements for a given date - and tells you which payments cleared, which didn't, and which need a human to look at them.

1. Flexible data intake

Data arrives however your banks and vendors already deliver it - you're not limited to one channel, and different source systems can use different channels at the same time:

There's no requirement to change an existing delivery process to start reconciling.

2. Automatic normalization and field mapping

Every source has its own file format and quirks. BankReconciliation parses each one and maps it into a single, consistent internal data model, so the matching engine never has to know where a record originally came from. For JSON sources we can auto-discover the fields in your first delivered payload and propose a draft mapping; other formats are mapped manually field by field. Until a mapping is confirmed and activated, incoming data is safely held - never discarded, never guessed at.

3. Automated, explainable matching

Normalized payments and statement lines are compared using a transparent, weighted scoring algorithm: the nostro account must match, and points are added for matching reference number, currency, date, and amount. High-confidence matches are applied automatically; everything else is routed to manual review. Tenants can layer their own custom matching rules on top of the defaults.

4. Audit trail and role-based access

Every action - ingestion, matching decision, manual override - is recorded in an append-only audit log that never contains secret values, raw payload content, or tokens. Access is role-based at two levels: platform roles (Super Admin, Platform Admin, Security Admin, Support) for cross-tenant operations limited to our own staff, and tenant roles (Tenant Admin, Client Admin, Reconciliation Operator, Auditor) scoped strictly to your organization's data. Every boundary is enforced server-side, never just hidden in the UI.

5. Secure, multi-tenant architecture

BankReconciliation is built as independent services with narrow, enforced boundaries rather than one monolith with shared access to everything: a dedicated identity service owns authentication and sessions, a dedicated connector service owns intake and integration credentials, and the application backend owns tenant data and reconciliation - each reachable only where it needs to be. Integration credentials (SFTP keys, API tokens, webhook signing secrets) live only in dedicated secret storage, never in application databases or logs, and are never returned via API or UI after initial setup. Raw data retention is a tenant-configurable policy from 1 to 365 days, defaulting to 30, so you control the window that matches your own compliance requirements.

6. Going live

Onboarding a connector follows the same four steps regardless of channel:

  1. Draft - configuration is created for your tenant: channel settings, credentials reference, field mapping.
  2. Test - a manual run or test delivery validates connectivity and mapping end to end before any schedule is turned on.
  3. Review - activation goes through an internal review step on our side, a safety gate rather than a delay you need to plan around once your first test succeeds.
  4. Activate - the schedule or live endpoint goes live, with normal monitoring and alerting applying from that point on.

Where we are today

BankReconciliation's security architecture - service isolation, secret management, MFA/RBAC, encrypted storage, immutable retention, and audit logging - is fully implemented end to end. We are transparent about where we are in our lifecycle: the platform is currently completing its first production rollout rehearsal ahead of onboarding pilot partners, and we are not yet formally certified under a framework such as SOC 2 or ISO 27001 - our controls are designed to align with those frameworks, and certification is on our roadmap as we onboard production customers.

Get in touch