Independent Product Studio & Open Source Lab.Explore active proofs
OPEN LAB TOOLS100% IN-BROWSER · ZERO SERVER CALLS · MIT LICENSED

Developer Utilities & Fintech Engines.

Production algorithms extracted directly from our open-source repositories (Abeta-dev/go-fintech-india ↗ and react-libs ↗). Run instant statutory checks and exact financial calculations with guaranteed privacy.

100% Client-Side & Zero-Server · Your inputs never leave your browser memory.
FINTECH ARCHITECTURE ADVISORY · B2B INBOUND

Building high-volume fintech, payment reconciliation, or RBI-compliant ledger architectures?

Consult directly with software architect Umesh Gupta & Abeta Open Lab. We architect zero-drift double-entry ledgers, automated statutory e-invoicing pipelines, and resilient payment gateway fallbacks for high-growth engineering teams.

Book Fintech Architecture Review ↗Direct architect advisory · 48h turn-around · NDA on request
100% Client-Side & Zero-Server · Your inputs never leave your browser memory.

UIDAI Verhoeff Checksum Validator

Mathematical dihedral group (D5) validation used across Indian national identity systems.

CHECKSUM INVALID / MISMATCH

Checksum mismatch: expected final check digit 4, but got 7.

Dihedral Group D5 Iteration Trace

Evaluating c = d[c][p[i % 8][digit]] across right-to-left reversed digits:

Pos (i)Digitp-row (i % 8)Permutation pPrior cResult c
070707
121770
212808
303880
494000
585000
676404
767342
850527
941275
1032357
1123176
Final state: c = 6. (In Verhoeff math, c == 0 signifies exact transmission integrity).
GO (ZERO-ALLOC)
// From github.com/Abeta-dev/go-fintech-india
package fintech

var dTable = [10][10]int{
    {0, 1, 2, 3, 4, 5, 6, 7, 8, 9},
    {1, 2, 3, 4, 0, 6, 7, 8, 9, 5},
    {2, 3, 4, 0, 1, 7, 8, 9, 5, 6},
    {3, 4, 0, 1, 2, 8, 9, 5, 6, 7},
    {4, 0, 1, 2, 3, 9, 5, 6, 7, 8},
    {5, 9, 8, 7, 6, 0, 4, 3, 2, 1},
    {6, 5, 9, 8, 7, 1, 0, 4, 3, 2},
    {7, 6, 5, 9, 8, 2, 1, 0, 4, 3},
    {8, 7, 6, 5, 9, 3, 2, 1, 0, 4},
    {9, 8, 7, 6, 5, 4, 3, 2, 1, 0},
}

var pTable = [8][10]int{
    {0, 1, 2, 3, 4, 5, 6, 7, 8, 9},
    {1, 5, 7, 6, 2, 8, 3, 0, 9, 4},
    {5, 8, 0, 3, 7, 9, 6, 1, 4, 2},
    {8, 9, 1, 6, 0, 4, 3, 5, 2, 7},
    {9, 4, 5, 3, 1, 2, 6, 8, 7, 0},
    {4, 2, 8, 6, 5, 7, 3, 9, 0, 1},
    {2, 7, 9, 3, 8, 0, 6, 4, 1, 5},
    {7, 0, 4, 6, 9, 1, 3, 2, 5, 8},
}

// ValidateAadhaar verifies a 12-digit number using zero-allocation D5 math.
func ValidateAadhaar(num string) bool {
    if len(num) != 12 || num[0] == '0' || num[0] == '1' {
        return false
    }
    c := 0
    for i := 0; i < 12; i++ {
        digit := int(num[11-i] - '0')
        if digit < 0 || digit > 9 {
            return false
        }
        c = dTable[c][pTable[i%8][digit]]
    }
    return c == 0
}

Need this in your Go microservice?

Run go get github.com/Abeta-dev/go-fintech-india for zero-allocation validators, IFSC lookups, and PAN parsers.

View on GitHub
TECHNICAL SPECIFICATIONS & STATUTORY STANDARDS

Frequently Asked Questions

01.

What is the Verhoeff algorithm used in Indian Aadhaar verification?

The Verhoeff algorithm is a mathematical checksum formula based on the dihedral group D5 (the non-commutative group of symmetries of a regular pentagon, order 10), invented by Dutch mathematician Jacobus Verhoeff in 1969. In Indian Aadhaar numbers issued by UIDAI, the 12th digit is an exact Verhoeff check digit. Unlike standard Luhn (Mod-10) algorithms, the Verhoeff checksum detects 100% of single-digit transcription errors and over 95% of adjacent transposition errors (e.g., swapping 23 to 32), which represent the vast majority of human data entry mistakes. It operates via multiplication (dTable), position-dependent permutation (pTable cycling through 8 permutations based on position), and inverse lookup (invTable) without requiring expensive division.

02.

How does Indian GSTIN 15-digit Mod-36 checksum validation work?

The Indian Goods and Services Tax Identification Number (GSTIN) is a 15-digit alphanumeric code adhering to ISO/IEC 7064 Mod 37, 36. Positions 1–2 represent the 2-digit state census code (01–38), positions 3–12 contain the taxpayer Permanent Account Number (PAN), position 13 denotes the entity registration sequence (1–9, A–Z), position 14 is the statutory default character "Z", and position 15 is the check character (0–9 or A–Z). Validation processes the first 14 characters from right to left using alternating weight factors of 2 and 1. Each character code point (0–35) is multiplied by the factor, quotient and remainder are summed, modulo 36 is computed, and the complement from 36 yields the expected 15th character check digit.

03.

Why does floating point arithmetic fail in Indian paise currency calculations?

Standard programming languages (JavaScript, Python, Go float64) use IEEE 754 binary floating-point arithmetic, which cannot accurately represent decimal fractions such as 0.1 or 0.2 in binary base-2 (resulting in artifacts like 0.1 + 0.2 = 0.30000000000000004). In Indian fintech applications—handling statutory GST calculations (0%, 5%, 12%, 18%, 28%), line-item discounting, UPI transfers, and payment gateway webhooks (Razorpay, Cashfree)—floating-point drift accumulates over thousands of transactions. This causes reconciliation discrepancies and audit failures. Production fintech systems store and compute all monetary values in exact 64-bit integer paise (where ₹1499.50 = 149950 paise) and apply half-up integer rounding for statutory tax splits.

MORE IN THE OPEN LAB

Need customized fintech pipelines or high-concurrency billing?

We build custom payment orchestration engines, tax compliance outboxes, and high-performance APIs for fast-moving businesses.

Talk to an Architect Explore Open Source Hub