DEV Community: Martins Chibueze

"Fingerprint, iris, or voice: which biometric fails first, and why fusion saves you"

Martins Chibueze — Thu, 15 Oct 2026 16:36:22 +0000

Biometric systems feel unbeatable - until you realize every single one of them can actually fail at one point just on its own.

Fingerprint Recognition

When a finger is placed on the sensor, the image is captured and converted to grayscale, and if there is noise (that's dust or dirt), the use of Gaussian or Median filtering (both are filtering techniques) is done which preserves ridge edges. The Contrast is then enhanced using Global Histogram Equalization and refined using CLAHE (Contrast Limited Adaptive Histogram Equalization), so the ridges become more distinct from valleys, especially in areas that were originally low-contrast, while the overall appearance remains natural.

Figure 1.1–2×2 deliverable grid: (a) Original fingerprint, (b) Noisy version with simulated salt-and-pepper noise, © Median-filtered result, (d) Final CLAHE-enhanced image.

Fingerprint Minutiae Extraction

These are the actual biometric features being extracted used for matching minutiae points - specifically ridge endings and bifurcations (points where a ridge splits into two). These discrete points, not the whole image, are what gets compared during fingerprint matching. Morphological thinning (cv2.ximgproc. thinning-Otsu's method) is then applied which reduces ridges to a 1 pixel-wide skeleton (finds the best threshold that separates the dark ridges from the light background.) and after that the Crossing Number (CN) algorithm is applied to every ridge pixel, where every part on the fingerprint image (Minutiae) the ridge end is identified in the CN as 1 (ridge ending) and anywhere the ridge divides into two, it is identified in the CN as 3 (bifurcation).

Figure 2.2 - Corrected minutiae map, after casting neighbour pixels to signed integers. Red markers indicate ridge endings; blue markers indicate bifurcations.

The system can have failures. Some of its failure modes are:

· Dry/worn fingers: When the skin is very dry, cracked, or heavily worn (manual workers, elderly people), the ridges become faint or broken, the system misses real minutiae, or invents false ones from the cracks and noise.

· Spoofing: Someone makes a fake fingerprint (silicone, gelatin, 3-D printed, etc.) and places it on the sensor. If the system only looks at the ridge pattern and does not check for signs of real skin (liveness detection), it can be fooled.

· genuine/imposter inversion: Normally we are supposed to have just

I downloaded 5 genuine and 5 imposter fingerprint images sourced from FVC2004 DB2_B, a publicly available academic fingerprint verification dataset containing 10 distinct fingers with 8 separate impressions (scans) of each finger.

This structure makes it possible to build genuine pairs (two different real scans of the same physical finger) and imposter pairs (scans from two different fingers). A batch script was written to automatically process every image in the dataset folder through a pipeline (binarize → thin → Crossing Number minutiae detection), summarize each fingerprint's minutiae into a fixed-length feature vector, and compute distances for 5 genuine pairs and 5 imposter pairs automatically.

It seems the images weren't the best quality, which caused problems - their boundaries got mixed up. In short: the system starts trusting strangers more than the real owner.

fingerprint images sourced from FVC2004 DB2_B

Figure A.5 - Strip plot of all 10 real distance scores. Green = genuine pairs, red = imposter pairs. The shaded orange band marks the region of direct overlap between the two classes.

In biometrics we talk about two kinds of comparisons:

· Genuine = same person (should get a high match score)

· Imposter = different person (should get a low match score) Inversion means the system has the scores the wrong way round: an imposter ends up with a higher score than a genuine pair. This is a catastrophic failure mode. It means the matcher is not just inaccurate - it is systematically ranking the wrong people as more similar. It can be caused by:

· very bad quality images,

· incorrect normalisation of scores,

· bugs in the matching algorithm,

· or (as in your lab finding) something going wrong in the extraction or comparison pipeline that flips the expected behaviour.

Iris recognition

Unlike fingerprints, the iris is a circular "doughnut" shape located between the dark pupil and the white sclera. So, we localize the iris (find the pupil and iris boundaries) and normalize it - transforming the ring-shaped region into a fixed-size rectangle using Daugman's Rubber Sheet Model, so that two captures of the same eye compare consistently regardless of pupil dilation or eye rotation. (Meaning the distance from the outer boundaries of the pupil to the outer boundaries of the iris so as a doughnut circle all iris is gotten through their, its then being cut at a side and stretch to a rectangle).

Figure 3.5 - Correct localization on eye3.jpg: red circle tightly bounds the pupil, green circle correctly follows the iris/sclera boundary, both properly concentric.

Figure 3.6 - Correct normalized iris strip for eye3.jpg. The radial, fibrous iris texture is visible consistently across the width of the strip - the expected output of Daugman's Rubber Sheet Model.

Iris recognition has extreme uniqueness: statistically, the probability of two independently formed irises matching is virtually zero - even identical twins have completely different iris patterns. Unlike fingerprints, which wear down, or faces, which age noticeably, internal iris patterns form during the pre-fetal period and remain stable from about one year of age onward. They're also resistant to spoofing because modern systems use liveness detection (analyzing pupillary light reflexes or multi-spectral illumination) to prevent attacks using high-resolution printed photos or artificial contact lenses.

It does still have weaknesses: eyelashes or eyelids can block part of the iris, and bright ambient lighting, stray reflections, or glare from eyeglasses can wash out critical detail or blind the sensor.

Voice biometrics

Voice biometrics (speaker recognition) is a behavioral and physiological biometric. Unlike a fingerprint or iris image, voice is a 1D signal that changes over time - the shape of a person's vocal tract filters air from the lungs into unique resonant frequencies. And the use of Mel-Frequency Cepstral Coefficients (MFCCs), the standard feature set representing the unique "timbre" of a human voice.

Figure 4.2 - Raw audio waveform of a spoken phrase, showing amplitude over roughly 9 seconds.

I recorded audio from my phone and converted it to a waveform using an audio converter, since it needs to be in WAV format to work. The waveform shows five distinct amplitude bursts separated by near-silent stretches, consistent with five separate spoken words in the test phrase, each showing the expected spike-and-decay pattern of natural speech.

Generated spectrogram by STFT(Short-Time Fourier Transform)

The spectrogram (visual representation of how the frequency content of the sound changes over time.) is then generated by the STFT, the image shows frequency energy concentrated in the lower bands with harmonic structure aligned to the voiced segments, typically in the 0–4000 Hz range for human speech. After the spectrogram, the pipeline continues to MFCCs (Mel-Frequency Cepstral Coefficients) where the spectrogram is passed through a Mel filterbank (which tries to mimic how the human ear perceives frequency), which results in a compact set of numbers (13 coefficients for every audio frame). These 13 numbers per audio frame form a matrix that acts as a voice biometric template. Each row of the resulting matrix represents one MFCC coefficient, with color indicating its value across time.

MFCC (Voice Biometric Template)

Even though voice recognition is very good, it still has weaknesses: accuracy decreases with background noise, replay attacks, and changes in voice caused by illness or fatigue.

Fusion

Recall the fingerprint inversion - imposter scores landing where genuine scores should be, and vice versa. Bringing in a second modality corrects it, and because the fused score averages fingerprint and voice together, this strong, cleanly-separated voice signal pulled every fused genuine score down and every fused imposter score up - correcting the fingerprint modality's backwards ordering entirely. In other words, real captured data demonstrated, without needing to be engineered or assumed, that a strong modality can compensate for and correct a weak one when combined through score-level fusion.

Strip plot comparing Fingerprint alone, Voice alone, and the Fused result. The bottom row (Fingerprint) shows visible overlap between green (genuine) and red (imposter) dots. The top row (Fused) shows the two-color groups pulled apart into distinct clusters

Conclusion: no single trait is foolproof; fusion isn't about "more security", it's about one modality catching what another misses.

“How cross-border money laundering hides in graph data — a Neo4j walkthrough”

Martins Chibueze — Mon, 31 Aug 2026 03:38:32 +0000

Using Neo4j to track money laundering, have you ever wondered how money laundering works? And why we shouldn’t use tables in tracking them.

Rule-Based Transaction Monitoring Systems

The dominant approach in AML compliance today is rule-based transaction monitoring, in which compliance teams define fixed rules that are evaluated against each incoming transaction. When a transaction matches a rule, an alert is generated and routed to a human analyst for review. In the normal banking system, they mostly use a role-based system for tracking money laundering, for example like “if money sent is > than $10,000 - Flag an alert”, which could raise a very much number of false alerts and routed to a human analyst for review.

The Graph Database Approach

The central innovation of RegTech AML is the use of a native graph database — specifically Neo4j — as the foundation for detection, rather than a relational database or a rule engine operating on isolated transaction rows. A relational database stores data in rows and columns. Finding relationships between entities requires joining multiple tables — an operation whose computational cost grows exponentially as chain depth increases. A query asking "find all entities connected to Person X through four or more intermediate companies" requires four successive table joins, each of which multiplies the data volume to be scanned. In a database containing millions of accounts and transactions, such a query is impractical in real time. As Napier AI (2024) notes: "Unlike relational databases which store data in rows and columns, graph databases excel in representing networks of entities and the dynamic relationship between them." Neo4j's native graph storage materialises joins as edges, allowing complex relationship queries to run in milliseconds rather than minutes.

The Three Detection Patterns

Shell Company Layering:
Shell Company layering is line of ownership, that ends up owning itself, for example like Company A owns Company B, Company B owns Company C, Company C owns Company D, Company D owns Company E then Company E owns back Company A, so that what makes it shell layering, A Company shouldn’t own’s its self-that’s a red flag.

Circular Flows:
Circular Flows is similar to the shell layering rounding, but it deals mostly with transaction, when the Account A transfers to Account B, Account B transfers to Account C, Account C transfers to Account D, Account D transfers to Account E and Account E transfers back to Account A, this is where the red flags lies, it’s should go back to itself.

Rapid Pass-Through:
Rapid pass-Through is when Account A, Account B, Account C, Account D, Account E all send money to Account X(hub account), Then Account X sends all the money to five other Account retaining less than 5% in the it’s account and all the transaction occurs within 1 hour, and that the red flag , because a company is supposed to retain some money in their account maybe for purchasing of goods and maintenances within Company, as long as All these transaction moves fast within an hour and still leaves less than 5%( account left empty ) that’s the problem.

Graph Visualization

Neo4j Browser provides native graph visualization of query results, rendering nodes as labelled dots and relationships as directional arrows. The following queries are optimised to produce visual graph outputs (rather than tabular results) for the purposes of demonstration:
So, this is the step-by-step process of visualization using Neo4j(Query)

VIZ 1 — SHOW THE ENTIRE DATABASE AS A GRAPH: it shows ALL nodes and relationships as a visual network.

Query: “MATCH (n) RETURN n”;

VIZ 2 — SHOW THE DATABASE SCHEMA (node types + relationship types): This shows the blueprint of the database — what types of nodes exist and how they are connected, without showing actual data.

Query: “CALL db.schema.visualization()”;

VIZ 3— SHELL LAYERING: Show the circular ownership loop as a GRAPH: Returns the shell company chain as a visual path — dots connected by arrows.

Query: “MATCH path = (a:Entity)-[:OWNS*2..6]->(a)
RETURN path;”

if an entity(company) owns any other entity(Company) from two to six and still owns back it’s self.

VIZ 4 — CIRCULAR FLOW: Show the money loop as a GRAPH: Returns the 5-account circular flow as a visual ring of dots and arrows.  ACC-CIRC-A → B → C → D → E → (back to A)

Query: MATCH path = (a:Account)-[:TRANSFERRED*3..6]->(a)
RETURN path;

VIZ 5 — RAPID PASS-THROUGH - Show the hub and its connections as a GRAPH: Returns the hub account with all its inbound and outbound connections.  a star shape — many sources feeding into hub, hub feeding many destinations.

Query: MATCH(src:Account)-[r1:SENT]->(tIn:Transaction)-[r2:RECEIVED_BY]->(hub:Account {account_id:"ACC-HUB-001"})
WITH hub, collect(src) AS sources, collect(tIn) AS inbound, collect(r1) AS sentRels, collect(r2) AS receivedRels
MATCH (hub)-[r3:SENT]->(tOut:Transaction)-[r4:RECEIVED_BY]->(dst:Account)
RETURN hub,
       sources, inbound,
       collect(tOut) AS outbound,
       collect(dst) AS destinations,
       sentRels, receivedRels,
       collect(r3) AS outSentRels,
       collect(r4) AS outReceivedRels;

VIZ 6 — SHOW ONLY THE SHELL COMPANY NETWORK (Entity nodes + OWNS relationships): This is the clean view of just the ownership structure, this explains Shell layer quite well, because in shell layering the Company A owns Company B, Company B owns Company C and Company C owns back Company A which hides the actual owner, but when the actual owner is then tracked, the entity is then known as UBO (Ultimate Beneficial owner) of all the Companies all together.

Query: MATCH (e:Entity)-[r:OWNS|UBO_OF]->(e2:Entity)
RETURN e, r, e2;

VIZ 7 — SHOW MONEY FLOW (Accounts + Transactions only): Shows only the financial movement — accounts as dots, transactions as nodes, this is still the rapid pass-through pattern and within the Transaction node the timestamp contain the actual time the money was sent or received, used to check if all the transaction all together was within one hour, that’s why by right of the screenshot, this is a line of transaction, which the time the money was sent and the time money takes more than an hour, which is normal

Query: “MATCH (src:Account)-[s:SENT]->(t:Transaction)-[rb:RECEIVED_BY]->(dst:Account)
RETURN src, s, t, rb, dst
LIMIT 30;”

VIZ 8 — SHOW FULL NETWORK FOR ONE SPECIFIC CRIMINAL (Victor Osei): This shows everything connected to Victor — his shell companies, accounts, transactions and showing how the graph reveals the full picture of one criminal.

Query: MATCH path = (v:Entity {name:"Victor Osei"})-[*1..4]->(n)
RETURN path;

Why This Reduces False Positives

Rule-based systems flag on single-transaction thresholds with no context, for example: if money sent > $10,000; flag an alert, there will be lots of alerts (false positives) but with the graph pattern, it give structural red flag for example: if there is a loop in the ownership, which is not supposed to be (which is against the rules  Abnormal) or a loop of transaction that also look abnormal too and also if there is a rapid transfer of money from different account to a single hub account which transfers the money to all other accounts just "5%" (percent is redundant with the % sign) of the money that’s very abnormal, and with the graph pattern a single node like an entity could store attribute like if KYC(know your consumer) is verified, if the entity is a PEP(Politically Exposed Person), if the country the transaction was made, or transferred to is on the gray list or black list, all these sum up to raise a red flag.

Risk Signal	Points Added	Rationale
Country on FATF BlackList	+50	Highest-risk regulatory environment; non-cooperation with global AML standards
Country on FATF GreyList	+25	Under active international monitoring; limited beneficial ownership disclosure
Circular ownership loop detected	+40	Structurally impossible in legitimate business; definitive shell indicator
KYC status not Verified/Pending	+20	Identity not confirmed; basic due diligence not completed
PEP flag (Politically Exposed Person)	+15	Elevated corruption risk by regulatory definition

The combined score determines the disposition:

Score Range	Disposition	Action
0–29	CLEAR	Transaction proceeds normally; no investigator action required
30–59	MONITOR	Logged automatically; analyst reviews at next scheduled triage cycle
60 and above	ESCALATE	Immediate manual review; Suspicious Activity Report (SAR) may be filed

The near-miss validation results demonstrate the effectiveness of this approach. For example: Hartfield Logistics Ltd — a verified UK holding company with a KYC-compliant three-tier structure — scores zero (CLEAR), despite making a USD 250,000 intercompany transfer. The shell network, by contrast, scores 85 (ESCALATE): Cayman Islands GreyList (+25), circular ownership loop (+40), KYC Pending (+20). Same structural complexity; completely different treatment. This is the mechanism behind the reported 0% false positive rate across all three near-miss validation cases.

Note: ”names are from a synthetic dataset used for coursework"

Conclusion:

Graph databases don't replace compliance teams, but they surface the shape of laundering that row-by-row rules miss entirely.