SERVICE LINE

Systems Integration

Most Nigerian institutions do not need another system. They need the eleven they already own to talk to each other reliably, securely and without a clerk retyping data at midnight. That is what this practice does.

Making separate systems behave as one

Integration is where most digital programmes quietly fail. A state government buys a revenue platform, a payroll system, a budget tool and a document management system from four vendors in four procurement cycles, and then discovers that none of them share a taxpayer identifier, a staff number or a chart of accounts. Our Systems Integration practice exists to close that gap. Working under Engr. Bashir Lawal Gezawa, Director of Infrastructure & Cloud, the team pairs software integration engineers with network and infrastructure specialists, because in practice the data problem and the physical connectivity problem arrive together.

On the software side we build enterprise service bus and API gateway layers that give an organisation one controlled front door for its interfaces, with authentication, rate limiting, transformation, retry and full message logging. We implement identity federation so that a single sign-on covers every application an officer touches, integrating with Active Directory and LDAP directories and, where the mandate allows, with national identity verification through NIN and bank verification through BVN. We connect collection systems to Nigerian payment infrastructure — Remita-style aggregators, NIBSS instant payment rails, card acquirers and agent-banking networks — and reconcile settlement files daily so that money received and money recorded actually match.

On the physical side we design and install the connectivity that integration assumes: structured cabling to TIA-568 standards, fibre backbones between buildings, access switching, wireless coverage surveys, and multi-site enterprise networks joined by SD-WAN over a mix of fibre, microwave radio and LTE. We also integrate biometric enrolment devices, smart-card and access-control systems, queue management, digital signage and CCTV into the same identity and network fabric, so that a single credential works from the gate to the general ledger.

Integration capabilities

Six areas of practice. Most engagements combine three or four of them.

API gateway and service bus

Message layer

A governed interface layer with authentication, throttling, transformation, routing, retry and dead-letter handling, plus a developer portal and full message audit for every transaction.

Identity federation

Single sign-on

SAML and OpenID Connect single sign-on across applications, integrated with Active Directory or LDAP, with multi-factor authentication and centralised joiner-mover-leaver provisioning.

Identity verification

NIN and BVN

Verification integrations against national identity and bank verification services, with consent capture, response caching, fallback handling and a tamper-evident verification log.

Payments and collections

Money movement

Payment gateway, aggregator and instant-payment integrations, card acquiring, agent-banking channels, automated settlement reconciliation and exception queues for unmatched items.

Biometric and card systems

Physical identity

Fingerprint and facial enrolment, deduplication, smart-card issuance and encoding, access control and time-and-attendance, integrated with the same directory as the software estate.

Cabling and enterprise networks

Physical layer

Structured cabling, fibre backbones, access and core switching, wireless surveys and rollout, and SD-WAN linking multi-site enterprise networks across states with automatic failover.

Integration patterns we use, and when

Choosing the pattern is the design decision that determines whether an integration is maintainable in three years. We publish our reasoning so that clients can hold us to it.

Pattern	When we use it	Typical technology	Trade-off to accept
Synchronous REST API	The caller needs an immediate answer — balance enquiry, identity verification, eligibility check	REST over HTTPS with OAuth 2.0, published as OpenAPI, fronted by the gateway	The caller is exposed to the callee going down; requires circuit breakers and sensible timeouts
Asynchronous messaging	Work can complete later — assessment notices, bulk enrolment, notification dispatch	RabbitMQ or Apache Kafka with durable queues, dead-letter handling and replay	Eventual consistency; the business must accept that state converges rather than matches instantly
Event streaming	Several systems must react to the same fact — a payment posted, a staff member exited	Kafka topics with schema registry and per-consumer offsets	Higher operational skill required; schema governance becomes a standing discipline
Batch file exchange	Legacy systems, bank settlement files, statutory returns, nightly general ledger posting	SFTP with PGP encryption, checksum validation, control totals and an exception report	Latency of hours; needs rigorous reconciliation and a documented reprocessing route
Database replication	Read-only reporting copies and warehouse feeds where the source cannot bear query load	Change data capture into a staging schema, then transformation into the warehouse	Couples to the source schema; must be re-tested whenever the source system is upgraded
Robotic process bridge	A closed legacy application with no interface at all, pending its replacement	Scripted UI automation with tightly scoped credentials and full action logging	Fragile and explicitly temporary; we contract it with a sunset date, never as an end state

A worked example: joining up state revenue collection

A northern state internal revenue service was collecting through six banks, three agent networks and a legacy assessment system that had no interface. Payments arrived in the treasury account days before anyone could attribute them to a taxpayer, and unmatched receipts had grown to a substantial fraction of monthly collection.

We built an integration layer in fourteen weeks: an API gateway in front of the assessment system, a NIN and taxpayer-identifier resolution service, direct connections to the collecting banks and the instant-payment rail, and an automated overnight reconciliation that matches settlement files to assessments and pushes exceptions into a work queue for the revenue officers. Taxpayers now receive an SMS confirmation with an attributed receipt within minutes.

Reconciliation that previously took a team of clerks eleven working days now completes before 06:00 each morning, and the unmatched balance fell by more than four fifths within two quarters. Figures are illustrative of typical engagements of this kind.

14 weeks from contract to production cutover
Six bank connections and two agent networks on one reconciliation engine
Overnight matching completing before 06:00 daily
Exception queue worked by revenue officers rather than by the vendor
Delivered alongside BrilliantRevenue at /solutions/government-revenue-platform

A worked example: joining up state revenue collection

Integration practice at a glance

210+

Interfaces in production

Built and under support

Multi-site networks

Designed and rolled out since 2014

Payment integrations

Banks, aggregators and agent networks

99.9%

Gateway availability

Measured across managed gateways, FY2025

Frequently asked questions

Our legacy system has no API at all. Is integration still possible?

Almost always, though the route matters. In order of preference we look for a supported interface, then a supported database read replica, then a file-based exchange, and only as a last resort a robotic bridge that drives the user interface. Where we use the last option we contract it with an explicit sunset date and a plan for what replaces it, because an undocumented screen-scraper left running for five years is how organisations end up in exactly the position they hired us to fix.

Do you supply the middleware licences or use open source?

Both, depending on scale and the client procurement position. For most engagements an open-source stack — Kong or APISIX for the gateway, Keycloak for identity, RabbitMQ or Kafka for messaging — delivers what is needed with no licence cost and full source availability. Where a client already owns Oracle, Microsoft or IBM middleware, or where a regulator expects a commercially supported product, we implement on that instead. The architecture document states the reasoning either way.

How do you protect data moving between systems?

All traffic is encrypted in transit with TLS 1.3, credentials are held in a secrets vault rather than configuration files, and every interface uses least-privilege service accounts scoped to specific operations. Message payloads containing personal data are minimised, sensitive fields are masked in logs, and retention on the message store is set to the shortest period the business can operate with. Designs are reviewed by our Cybersecurity practice before they go live and tested against NDPA obligations.

Can you certify or approve identity verification integrations?

We implement against the published interfaces of the relevant identity and verification services, and we handle consent capture, audit logging and access control to the standard those services require. Approval to consume such services rests with the client organisation, which must hold the appropriate authorisation and data-sharing agreement. We routinely support clients through that application and supply the technical annexes it needs.

What does a cabling and network rollout include?

Site survey and heat mapping, cable schedule and containment design, installation of Cat6A or fibre to agreed standards, patch panel and rack build, labelling to a documented convention, Fluke certification of every link with results supplied as a report, switch configuration, wireless controller setup, and as-built drawings. We warrant the passive installation for fifteen years through our cabling partners and the active configuration for twelve months.

Who owns the integration once it is live?

You do. Interface specifications, gateway configuration, schemas, runbooks and monitoring dashboards are handed over and can be operated by your team. Many clients ask us to continue running the gateway under a managed-service retainer, which is a commercial choice rather than a technical necessity. See /services/managed-it for how that works.

Where integration work usually leads

Integration engagements frequently sit alongside our hosted platforms. BrilliantCloud at /solutions/managed-cloud provides the runtime for gateway and messaging components, and BrilliantInsight at /solutions/business-intelligence-suite consumes the data those interfaces expose.

For sector-specific integration patterns, see Financial Services at /industries/financial-services and Telecommunications at /industries/telecommunications.

Systems that will not talk to each other?

Describe the estate and the reconciliation that is currently done by hand. We will map the interfaces, propose the patterns, and price the work — including the parts you can do yourselves.

Request a Quote Financial services work Managed cloud