Confidential · Phase 1 Deliverable · For MK Fraud Insights
The formal Phase 1 design output: a deterministic, transparent, MK-editable scoring engine, the recommended architecture, the data model, the security and cost approach, the implementation roadmap, and a working scoring proof of concept.
The MK Fraud Readiness Score is produced by a rule engine that treats your methodology as configuration, not code. The calculation is a pure deterministic function, score(config, answers): the same applicable answers under the same configuration version always produce the same overall score, category scores, maturity band, exposure profile, and recommendations. There is no randomness, no time dependence, no model inference, and no network call inside the calculation. Generative AI never determines, alters, or overrides the score. Every result carries a full per-domain and per-answer trace showing each weight, each critical-control check, and any maturity cap that fired. Questions, weights, maturity bands, critical-control rules, exposure variables, and recommendation text all live as versioned, MK-editable data, so your team changes the methodology without a developer and without a release. A scoring test pack proves expected equals actual before anything goes live. The methodology is yours; Aveosoft builds the system that executes it faithfully. This commitment is the first thing this pack states because it is the heart of the product.
We have reviewed the brief line by line and validated the product MK is building: an established document-based Fraud Readiness Diagnostic across ten capability domains, delivered as a scalable digital product that organisations complete online to obtain a structured, credible view of their fraud readiness and a 30, 60, and 90-day plan to act on it. Three output levels are designed for from the start: an Instant Snapshot, a Full Self-Assessment Report, and an MK-Validated Report, with the validated level supported by a manual MK workflow at launch.
This engagement hands Aveosoft a clear engineering and configuration boundary, which removes the single largest risk on assessment products: a vendor inventing or quietly distorting the scoring model. The residual risk picture concentrates in five places, each with our recommended handling already attached.
Some materials may be refined during the design phase, making scope and scoring a moving target. Mitigation: hold the methodology as versioned, externalised configuration so changes never need code edits; lock a baseline version for the proof of concept; written change control re-tests and re-versions any post-acceptance change.
A silent calculation error or an untraceable score would destroy the credibility that is the product's entire value. Mitigation: an expected-versus-actual reconciliation harness from an MK-approved test pack, a per-answer trace, fully deterministic calculation, and a hard launch gate. No production launch until scoring reconciles against the approved test cases.
If a failed control does not cap maturity, a weakness hides behind a healthy average. Mitigation: model flags and caps as explicit configurable rules, verified by dedicated test-pack scenarios where each failure must demonstrably cap maturity.
A lapse is both a POPIA exposure and a trust failure. Mitigation: the POPIA-aligned approach in Section 09, MK ownership and export of all data, all accounts under MK credentials, and an absolute rule that no client or methodology data trains any public AI and no AI sits in the scoring path.
Phase 1 is standalone and MK may appoint a different supplier afterward, while a feature-rich Phase 3 backlog invites MVP inflation. Mitigation: scope and price Phase 1 as a complete, handover-ready deliverable usable by any supplier; restate the out-of-scope list; confirm the MVP automates only the Snapshot and Self-Assessment Report; written change control prices additions separately.
The respondent journey is designed to maximise completion of a long professional assessment while keeping the scoring honest. The organisation profile is captured first, which drives conditional applicability so each respondent only sees questions relevant to their operating model. Responses persist server-side with save-and-return, so no answer is lost if a session is interrupted on a normal South African connection.
The organisation profile is captured, then the engine evaluates applicability conditions to build the applicable question set. Genuinely non-applicable questions are excluded and weights are renormalised so the out-of-100 scale stays fair.
The respondent works through the ten capability domains with progress, help text, and save-and-return. Each response is keyed per question with a recorded respondent, so multi-respondent contribution becomes an additive change later, not a rebuild.
On submit, the deterministic engine computes readiness, exposure, critical-control outcomes, the maturity band after caps, recommendations, and the full trace. The Instant Snapshot renders on-screen with readiness and exposure shown separately.
On a paid or granted basis, the deterministic report generator produces the branded report. MK admins review, validate, add approved commentary, and regenerate or reissue as a new version. An anonymised benchmark record is written on completion.
The data-flow diagram below shows the end-to-end path from profile capture, through the scoring engine and its trace, to report generation, immutable storage, the MK admin dashboard, and the anonymised benchmark projection. A separate methodology side flow shows MK editing the configuration into a new version, running the test pack, and optionally recomputing history non-destructively.
The real decision is not whether to write code; it is how to host a deterministic, MK-editable scoring engine so it stays transparent, owned, and able to grow. We weighed the recommended custom build against the realistic alternative the brief invites, a configured low-code assessment platform. We recommend Option A.
| Evaluation area | A · Custom modular monolith + config engine (recommended) | B · Configured / low-code platform |
|---|---|---|
| Initial cost | Moderate, scoped to an SME MVP | Lowest to start |
| Recurring cost | Modest, predictable managed-service lines | Per-seat or per-response fees that grow with volume |
| User experience | Full board-grade MK brand control | Constrained by platform templates; can read as a survey |
| Scoring flexibility | Full: versioned config, caps and gates, dual model, traces | Limited; complex caps, gates, and dual scoring hit a ceiling |
| Reporting | Full dynamic branded report, immutable finals | Templated, hard to make board-grade and immutable |
| Security | We control hosting, region, encryption, RBAC for POPIA | Depends on the platform's posture and region |
| Data ownership | Total: MK's own database, full export | Often partial, shaped by the platform |
| Vendor lock-in | Lowest: open stack, portable schema | Highest: methodology and data trapped in the platform |
| Maintainability | MK self-admins; one app any competent dev can run | Easy until platform limits, then blocked |
| Scalability | SME to thousands without a rebuild; seams ready to split | Scales, but cost scales with it |
| Integration | Clean subdomain, open API, webhooks | Only the platform's allowed connectors |
| Benchmarking | Owns the anonymised dataset, structured for the Index | Data lives inside the platform; harder to own |
| Handover | One codebase, schema, config, test pack, docs | Platform-specific skills, tied to the platform's longevity |
Why the custom build is recommended. The brief's heaviest, repeated demands are deterministic and traceable scoring with caps and gates and a readiness-versus-exposure separation, MK self-editing without code, total data ownership and zero lock-in, board-grade branded reporting with immutable finals, and an owned dataset for future benchmarking. A configured low-code platform is the cheapest, fastest start, and the brief rightly asks us to weigh it, but it puts a ceiling on exactly what MK ranks highest, and it traps the confidential methodology and the client dataset inside a third party where leaving means a rebuild. The custom build is the only option that scores full on scoring flexibility, reporting, data ownership, lock-in, and handover at once, at a build cost that is reasonable at SME scale.
We recommend a custom web application built around a versioned scoring and rules engine and an MK admin console, deployed on a dedicated MK subdomain with every account under MK-controlled credentials. The methodology lives as data, not code. This is deliberately pragmatic engineering for an SME launch: a modular application and one primary database, not an enterprise microservices estate.
Board-grade, responsive, MK-branded interface that loads well on normal South African connections, with progress, save-and-return, and conditional logic. Server rendering helps first paint and product SEO.
One deployable with clear module seams: assessment, scoring, reporting, admin, payments, and communications. The same TypeScript language end to end keeps the team small and the handover simple.
Deterministic, testable, traceable. Reads versioned configuration and emits a score plus a full trace. No black box, no model inference, no external runtime in the calculation path.
Relational integrity for the methodology and results, strong aggregation for the dashboard and the benchmarking dataset, fully portable, easy to export and hand over.
One template path drives both the on-screen report and the PDF, with full MK control of fonts, colours, charts, and layout, and immutable final reports.
Stores generated PDFs, brand assets, and later evidence uploads. Versioned, encrypted, signed-URL access, keeping issued finals immutable.
The data model is the structural answer to the central requirement: everything MK provides becomes rows MK can edit, not code we ship. Domains, questions, response options and values, question and category weights, applicability conditions, critical-control rules, maturity bands and caps, recommendation and strength triggers, and exposure variables all belong to a scoring configuration version with a status of draft, active, or retired.
The scoring engine is the heart of the product. It is a pure deterministic function of the active methodology version and the applicable answers, with two separate dimensions, explicit critical-control gating, and a full trace on every run. To prove this is real rather than aspirational, we have built a runnable scoring proof of concept on the proposed Phase 2 stack, so the engine carries directly into the build.
Fraud Readiness (capability across the ten domains) and Fraud Exposure (inherent opportunity from the operating model, channels, third parties, and geography) are computed by two distinct passes and presented side by side, never averaged into one number.
Critical-control questions are flagged; maturity caps are explicit rules. A failed critical control caps the maturity band regardless of a healthy average, force-lists the gap, and pushes it up the priority ranking.
Every run records each answer's value and weight, its contribution to the domain, the overall roll-up, the critical-control evaluation, the maturity decision before and after caps, and which questions were excluded as not applicable and why.
Named sample response sets with MK-approved expected results run through the real engine and produce a field-level difference report. The launch gate: no production launch until scoring reconciles against the approved test cases.
The proof of concept is real, runnable Node code. It implements the exact scoring design specified in this pack: the configuration data model, the two-model readiness and exposure separation, critical-control gating, the score trace, and the test-pack mechanism. It runs on Node with a JSON methodology configuration, mirroring the proposed Node and PostgreSQL stack with zero proprietary rules engine in the path, and ships with a fourteen-case expected-versus-actual test pack (ten scoring cases and four report cases). The methodology values inside it are an illustrative sample; MK provides the real methodology.
The sample organisation's weighted readiness score of 61.25 alone would read as the Established band. The engine caps it to Developing because the independent, confidential whistleblowing critical control failed: a high average cannot mask the gap. Fraud Exposure is 75 / 100, the Severe level, which combined with only Developing readiness automatically triggers a priority intervention recommendation. The engine emits a full per-domain and per-answer trace explaining the cap, the exclusions, and every contribution.
Per-domain readiness breakdown from the sample run. The two failed domains, Whistleblowing & Reporting and Data, Analytics & Monitoring, both score 37.5, and the whistleblowing failure is the critical control that drives the maturity cap.
| Capability domain | Score / 100 | Note |
|---|---|---|
| Governance & Fraud Risk Ownership | 75 | Board-approved fraud risk policy critical control passed |
| Fraud Risk Assessment | 62.5 | |
| Preventive Controls | 75 | |
| Detective Controls | 62.5 | |
| Whistleblowing & Reporting | 37.5 | Independent, confidential whistleblowing critical control failed: drives the cap |
| Investigation & Response | 50 | |
| Third-Party & Vendor Risk | 62.5 | |
| Data, Analytics & Monitoring | 37.5 | Lowest-scoring capability alongside whistleblowing |
| Culture, Awareness & Training | 75 | |
| Policy & Regulatory Compliance | 75 |
Reports are assembled from MK-approved material only, generated deterministically from the scoring result, the trace, and the organisation profile. There is no unrestricted AI making risk decisions or inventing recommendations. A single HTML and CSS template set drives both the on-screen report and the PDF render, so MK gets full brand fidelity in both surfaces and there is one place to maintain.
The Protection of Personal Information Act is the relevant frame, and the platform is designed to it from the start. All production accounts are created under MK-controlled credentials and billing, so MK owns the system and Aveosoft holds working access only.
Each third party is a commodity service with a drop-in alternative, configured under MK-owned accounts. The figures below are rough monthly estimates in USD for an SME launch, confirmed during the build phase. The custom architecture carries no mandatory per-seat or per-assessment platform licence.
| Service | Provider examples | Monthly (USD est.) |
|---|---|---|
| App and database hosting | Managed app host plus managed PostgreSQL | 40 to 80 |
| Object and file storage | S3-compatible | 5 to 15 |
| Transactional email | Postmark or Amazon SES | 0 to 15 |
| Report generation | Runs in the application tier | 0 |
| Analytics | Privacy-respecting analytics | 0 to 15 |
| Domain, DNS, TLS | MK registrar plus managed TLS | 1 to 5 |
| Backups and monitoring | Automated backups, uptime monitoring | 5 to 20 |
| Payments | PayFast, Yoco, or Peach Payments | Per-transaction; no fixed monthly |
| Indicative total at launch | Predictable, grows gently with volume | ~75 to 120 / mo |
Vendor lock-in is low by design. The stack is open and standard (React, Node, PostgreSQL, HTML to PDF), with no proprietary runtime holding the methodology or data. Every third party is swappable behind a thin adapter: PostgreSQL is portable across providers, object storage is S3-compatible, and email, payment, and analytics providers are commodities. Full data export of raw responses, scores, traces, reports, and configuration means MK can leave any provider or hand the whole system to another competent developer with the code, schema, scoring configuration, report templates, and test pack in hand. The only lock-in is to open, widely supported technology, which is the desirable kind. A low-code platform, by contrast, would hold the confidential methodology and the client dataset inside a third party where leaving means a rebuild.
Phase 1 is a standalone, handover-ready deliverable. Phase 2 builds the MVP under milestone acceptance, with the fixed price confirmed at the close of Phase 1 once requirements are validated. Phase 3 enhancements follow by milestone as MK chooses.
This pack: requirements validation, the assumptions and risk register, the customer-journey and workflow design, two implementation options and the recommended architecture with diagrams and database structure, the security, recurring-cost, and vendor-lock-in assessments, the implementation roadmap, the fixed-price build proposal, a clickable prototype, and the demonstrated sample score and report.
The assessment interface, organisation profile, conditional logic, and save-and-return; the scoring engine with category and maturity rules, the exposure profile, and critical-control logic; the MK admin console; the snapshot results; full report generation; email workflows; basic payment and access control; data export; subdomain deployment; analytics; testing; documentation; training; and production launch. The single fixed price is confirmed at the close of Phase 1.
Multi-respondent assessments, client accounts and portals, evidence uploads, the MK validation workflow, reassessment comparison, benchmarking, dashboards, subscriptions, additional sector modules, API integrations, and the annual Fraud Readiness Index.
This pack evidences the Phase 1 design deliverables. The clickable prototype and the scoring proof of concept are live artifacts delivered alongside this document. The table maps all eighteen items to where each is evidenced.
| # | Section 10 Phase 1 deliverable | Where it is evidenced |
|---|---|---|
| 1 | Requirements validation | Section 01 of this pack |
| 2 | Assumptions, risks, open decisions | Section 02 of this pack |
| 3 | Customer-journey design | Section 03 of this pack |
| 4 | Assessment and report workflow | Section 03 of this pack and the data-flow diagram |
| 5 | Two viable implementation options | Section 04 of this pack |
| 6 | Recommended technical architecture | Section 05 of this pack |
| 7 | Architecture diagram | Section 05, embedded diagram |
| 8 | Data-flow diagram | Section 03, embedded diagram |
| 9 | Proposed database structure | Section 06 of this pack and the ERD |
| 10 | Proposed report-generation method | Sections 07 and 08 of this pack |
| 11 | Security and access approach | Section 09 of this pack |
| 12 | Third-party platform assessment | Section 10 of this pack |
| 13 | Recurring cost estimate | Section 10 of this pack |
| 14 | Vendor-lock-in assessment | Section 10 of this pack |
| 15 | Implementation roadmap | Section 11 of this pack |
| 16 | Fixed-price build proposal | Section 11 of this pack (USD 8,000 to 12,000, confirmed at close of Phase 1) |
| 17 | Clickable prototype | Separate live artifact, delivered alongside this pack |
| 18 | Demonstration of a sample score and report | Section 07; the runnable scoring proof of concept, a separate live artifact |
The six items in Section 02 shape the scoring design and the Phase 2 commercial features.
We are ready to sign so MK can share the questions, weights, maturity bands, critical-control rules, exposure variables, and recommendation library that replace the illustrative sample.
With requirements validated, the single fixed Phase 2 price is confirmed and the build proceeds under milestone acceptance, carrying the proven scoring engine directly forward.
By the close of Phase 1 MK holds validated requirements, a recommended architecture with diagrams and database structure, the security, recurring-cost, and vendor-lock-in assessments, an implementation roadmap, a fixed-price build proposal, a clickable prototype, and a demonstrated and runnable sample score and report. That pack is valuable on its own and it is the strongest possible basis for the Phase 2 build.