System Case Study · Fintech · Shariah-Compliant Data · Kenya
SIBK wanted live Nairobi Securities Exchange pricing on their site, but not the whole exchange. They're a Shariah-compliant investment bank, so only Shariah-certified counters can ever reach a customer-facing screen. Anything else isn't a display bug, it's a compliance breach. I knew that ruling-out had to be structural rather than editorial, because any workflow where a person could forget to filter a page before publishing it would eventually fail.
The data itself also had to be trustworthy before it could look trustworthy. NSE end-of-day figures arrive either by vendor API or by manual file drop depending on the day, and either path can hand over malformed rows, stale dates, or an implausible price spike. I couldn't let any of that reach the public site, and I couldn't let it quietly corrupt the historical record either.
I built a WordPress plugin that treats market data ingestion as a compliance and security problem first, and a display problem second. Two adapters, a vendor REST API and a manual file drop, feed one pipeline: validate, filter against a bank-maintained Shariah allowlist, then store. Nothing reaches the public site, the ticker widget, or the market table until it has cleared every gate.
Follow a single price from the exchange to the screen. The spine below is the path every row takes. Press Play the flow to watch it move, or tap any stage to read what happens there. Underneath are the pieces that make it run, grouped by job; tap any one for the plain-English version.
Note: this shows the real pipeline architecture and stage names from the plugin I shipped. I've left out vendor endpoint details, credentials, and the live allowlist contents, since those are confidential to SIBK.
I wrote a REST adapter that pulls end-of-day data from a vendor API on a daily cron, with HTTPS enforced, the API key sent via header, and response size capped before parsing. I paired it with a File Drop adapter that watches a protected upload directory every 15 minutes during the post-market window, for the days data arrives manually instead. Both implement the same interface and feed the identical downstream pipeline, so neither source gets a lower-scrutiny path.
I made a versioned list of SCO-certified NSE tickers the compliance gate that every record has to clear before it's stored. The version string gets stamped onto every saved price row and logged on every ingest run, so you can always audit which allowlist revision was in effect for any given day's data.
| Check | Rule |
|---|---|
| Required fields | Ticker, price, and trade date must all be present |
| Ticker format | 2–10 uppercase letters, matched against a strict pattern |
| Price bounds | KES 0.01–10,000; anything outside is rejected, not clamped |
| Change sanity | Single-day change beyond 30% is dropped as implausible |
| Trade date | Rejected if in the future or more than 7 days stale |
| High/low consistency | High below close, or low above close, is nulled as a data error |
| Batch sanity | Payloads over 500 records, or >20% invalid rows, halt the whole batch |
I kept the REST surface minimal: /wp-json/sibk/v1/prices and /status serve Shariah-certified closing prices to the frontend. I exposed no public write endpoints, sanitise output before it leaves the server, and rate-limit per IP with cached responses so the endpoint stays cheap under load.
I built an admin screen that shows feed health at a glance: status, last successful run, live vs. approved ticker counts, and allowlist version, with a staleness warning if 26+ hours pass without a successful ingest, which means a missed trading day. There's also a full ingest log and one-click manual ingest buttons for both adapters, so the team can troubleshoot without touching a server.
I wrote a bridge class that feeds live prices into the site's ticker and market-table widgets through a WordPress filter. It falls back to the theme's built-in sample data on its own until the first successful ingest has run.
This plugin sits closer to a bank's compliance boundary than a typical content feature, so I built it with the file-handling and credential-storage discipline that implies.
realpath() containment), size limit, extension whitelist, actual MIME type rather than just the extension, symlinks, and embedded PHP or script tags, all before a single byte is parsed..htaccess deny-all and a dummy index.php, so nothing in it is ever directly reachable or executable over HTTP.$wpdb->prepare(). There's no raw SQL interpolation anywhere in the storage layer.wp-config.php rather than in the codebase, with autoloading disabled.| Before | After |
|---|---|
| Market data display depended on manual, ad hoc filtering | Shariah compliance enforced structurally: non-approved tickers never reach storage |
| No standard path for vendor outages or bad data days | Two independent adapters (API + file drop) with identical validation, so one path can cover for the other |
| No audit trail for what data was shown, or when | Every ingest logged with per-stage counts and the allowlist version in effect |
| Failures would surface only if someone happened to check | Automatic email alert after repeated consecutive failures |
It's running in production now, ingesting NSE end-of-day data daily and serving Shariah-certified pricing to SIBK's ticker, market table, and public API. The compliance and data-quality checks are built into the pipeline itself rather than bolted on afterwards.
If this is you
If you depend on data that has to be accurate and on time, I build you the pipeline that delivers it and stays out of your way.
Back to
All Systems →
Whatever you need built, I design and ship it end to end, from an internal tool to a full-stack product. Tell me what should already exist.
Talk to Me →