Confidential Fraud-Graph Computation Architect — Banking Consortium

The mandate

Member banks can identify suspicious accounts within their own boundaries, while coordinated mule and beneficiary structures become visible only across institutions. Pooling identifiable transactions would create disproportionate privacy, banking-secrecy and security exposure. Earlier proofs showed cryptographic feasibility but did not resolve query leakage, party dropout, correction, investigative explanation or who may convert a confidential signal into customer action.

The deliverable is a Confidential Fraud-Graph Computation Architecture for three bounded typologies, covering participant identity, permitted input, entity resolution, private set operations, secure aggregation, threshold key control, query approval, result disclosure, evidentiary caveat and deletion. It will compare cryptographic and confidential-compute patterns without presuming one technology or creating an opaque collective blacklist.

Milestone one at week four supplies legal-purpose boundaries, threat models and measurable typology journeys. Week nine concludes milestone two with computation protocols, governance and leakage budgets. By week sixteen, milestone three delivers reference executions and hostile-participant tests. The accepted architecture, operating charter, supplier requirements and member qualification suite complete milestone four at week twenty-two.

Acceptance requires member teams to reproduce twelve unseen signals from authorised inputs through disclosed result without revealing another bank’s underlying records; one participant dropout and one corrected identifier must complete safely; and independent privacy and model-risk reviewers must reperform leakage tests. Council chairs sign after investigators explain both a signal and a justified non-disclosure without consultants.

Members will provide synthetic and controlled replay datasets, typology definitions, legal-basis analyses, entity schemas, threat intelligence, existing vendor terms and named privacy and fraud owners. Client engineers implement references inside approved secure environments. The engagement excludes production deployment, customer action, suspicious-activity determination, legal opinion, model validation, enforcement referral and procurement negotiation.

Why this is external work

Each bank can defend its own data, but no member can credibly design consortium controls while also maximising its investigative visibility. Cryptography vendors naturally optimise for their mechanism. External architecture supplies neutral threat analysis and acceptance evidence while leaving legal basis, fraud judgement and customer treatment with accountable member institutions.

What you will own

• Map authorised purpose, member input, private linkage, graph computation, threshold approval, result disclosure, investigation and deletion evidence.
• Define leakage limits for membership, query frequency, result size, auxiliary information, collusion and repeated computation across typologies.
• Design participant dropout, key rotation, data correction, late contribution and consortium exit without exposing another member’s records.
• Exercise malicious query, poisoned identifier, colluding participants, unavailable key holder, replay attack and unjustified result expansion.
• Specify explanations that show why a cross-bank signal exists without disclosing protected counterpart data or implying guilt.
• Compare multiparty computation, trusted execution and federated patterns through threat fit, latency, auditability, portability and operating cost.
• Transfer protocol qualification, leakage review and incident exercises to permanent member-bank privacy, fraud and security owners.

Candidate qualifications

• Directed secure multiparty, confidential-compute or privacy-preserving analytics architecture across separately accountable regulated institutions.
• Designed private linkage and graph or aggregate computations while bounding query, membership, output and auxiliary-information leakage.
• Governed key ceremonies, party dropout, malicious participants and result disclosure under realistic consortium operating conditions.
• Worked with fraud investigators and model-risk teams without turning probabilistic cross-member signals into unexplained adverse customer decisions.
• Translated banking secrecy, privacy purpose and evidentiary limits into testable computation and deletion controls across jurisdictions.
• Delivered vendor-neutral reference architecture that member engineers and independent reviewers could rerun after external closure.

Non-negotiables

• The named architect must lead Singapore threat sessions and hostile-participant acceptance tests inside approved secure facilities.
• No financial relationship may exist with confidential-compute, identity-resolution or fraud-platform suppliers assessed.
• Member institutions retain legal basis, investigation, reporting and every customer-impacting decision.
• Raw identifiable member records cannot be pooled, exported or retained as consultancy test material.

1. 49 words maximum. Describe a confidential computation whose result leaked more about participants than its designers expected.
2. 49 words maximum. How would you explain a cross-bank fraud signal without exposing another institution’s contributing records?
3. 49 words maximum. Which client inputs are indispensable before a malicious-query acceptance test can begin?