Genius Hacks 2026 - Myridius AI Innovation Hackathon
Myridius AI Innovation Hackathon 2026

Genius Hacks

Infinite Ideas. One Genius Community

One loosely defined business problem. Five weeks. Take it from a half-page brief to something production ready, using AI at every phase of delivery, and be ready to explain every decision you made along the way.

Registration Deadline 2 September 2026
Submission Deadline 30 September 2026
Register Now See the Challenge
Scroll

Unleash the Myriad of Genius in You

Genius Hacks 2026 asks you to take a loosely defined business problem and drive it to a production-ready outcome using AI across the entire software development lifecycle. You will be judged on how you apply AI within each phase of delivery, govern it, evaluate it and decide where humans stay in the loop.

Participants will not be evaluated on the AI model they use. They will be evaluated on how effectively they design, orchestrate, govern, evaluate and operationalise AI-driven software delivery from requirement through production.

The Challenge

Every team works on the same problem statement. It is deliberately short and incomplete, because refining it is part of what is being assessed.

The Problem Statement

Risk Assessment Workbench

Automating financial crime risk assessment for new products and changes

The Client

A banking and financial services leader: a large national bank with roughly half a trillion dollars in assets, spanning consumer banking, commercial banking, payments and wealth management, closely supervised and examined on how well it controls financial crime risk.

The Business Problem

Every time a business unit wants to launch a new product, add a feature, change a process, onboard a vendor, enter a new geography or open up to a new customer segment, the Financial Crimes Risk Management (FCRM) function must assess the financial crime risk it introduces before it goes live. The outcome decides whether it is approved, rejected, deferred or approved with conditions.

Today that process runs on email, Word, Excel and SharePoint, and depends heavily on which analyst picks up the case and what they happen to remember. A single assessment takes fifteen to twenty business days, two analysts can reach different conclusions on the same change, and when an examiner asks months later why a risk was rated the way it was, reconstructing the answer is slow and often incomplete.

What They Want Built

A Risk Assessment Workbench: one governed platform that carries a change request from intake through assessment to a committee decision, replacing the email and spreadsheet trail. Workflow, scoring and record-keeping are automated. AI is applied where it earns its place, typically finding relevant policy, pulling structure out of submitted documents and drafting the assessment for review. It serves three groups: a product owner who raises the change, an FCRM analyst who finalises the assessment and owns platform configuration, and a risk committee that votes on the result.

What Good Looks Like

  • Intake to decision-ready in around two days, against fifteen to twenty today
  • Every rating traceable to its inputs and reasoning
  • Foundational data for AI: a modelled, governed data layer the system can actually reason over
  • Scoring parameters and workflow rules tunable by the risk function
  • An immutable audit trail that can be handed to an examiner
  • The system prepares, humans decide. Nothing is approved or rejected automatically

Constraints Worth Knowing

  • Risk decomposition grounded in published supervisory frameworks, not invented. Finding the right ones is part of the exercise
  • Controls mitigate risk; they never eliminate it. Scoring must respect that
  • A human can disagree with any system output, record why, and have the consequences handled
  • Synthetic data only. No connection to any real system

Deliberately Not Specified

These are the decisions being assessed. Make them, and be ready to defend them.

  • Which parts of the workflow are automated, which use AI and which stay manual
  • How risk is scored
  • Where the human checkpoints sit
  • Which stack you use

What You Must Demonstrate

Your submission should show AI applied across all six stages of delivery, not just code generation.

STAGE 01

Requirements

Understanding the business problem, expanding a vague brief into a working specification and conducting the research needed to fill the gaps.

STAGE 02

Design

Solution and technical architecture, data model design, user experience decisions and the tools used to reach them.

STAGE 03

Development

Code generation, data engineering, agent orchestration and the tool chain that connects them.

STAGE 04

Testing

Validation, quality assurance and test automation.

STAGE 05

Deployment

Production deployment approach and go-live path.

STAGE 06

Operations

Monitoring, observability and continuous improvement.

How You Will Be Judged

Expect the panel to probe decisions rather than features. Every choice you made should have a reason behind it.

30%
AI harness and agent orchestration
Your architecture, how work is orchestrated, how context is managed, the data foundation the harness runs on, your instruction design, and how you divided the work between AI and people.
20%
SDLC automation
How effectively AI is applied within each of the six delivery stages, and how those stages connect into a coherent flow rather than isolated experiments.
15%
Human-in-the-loop and governance
Your review gates and the rationale for each. What risk is this gate controlling, and why is it placed here?
10%
Evaluation framework
How you know the output is good. What you measure, how you measure it, and how failures feed back into improvement.
10%
Context engineering and requirement expansion
How you researched an incomplete requirement, layered in domain knowledge and maintained that context across the workflow.
5%
Production readiness
Scalability, security, architectural standards and reliability. A demo that works once is not the bar.
5%
Token efficiency
Which models you used, where consumption concentrated and what you did to optimise it.
5%
Engineering judgement
Distinguishing deterministic from probabilistic problems, and justifying where you chose traditional logic over an LLM.

What we are not evaluating

  • Which AI tool or assistant you use
  • Who generates code fastest
  • Raw output volume
  • Polished looking output without underlying engineering

Key Dates

Mark these now. The registration window is short.

2 Sep

Registration Deadline

Team registrations close at end of day. Register early rather than on the last day.

30 Sep

Submission Deadline

Repository access and presentation due at end of day. Commits after this point are not assessed.

To be announced

Final Presentations

Shortlisted teams present to the jury panel, followed by questions on their decisions.

To be announced

Awards

Winners announced and recognised.

What You Submit

Two things, both due 30 September. Most of the rubric lives in the repository rather than the deck, so treat the repository as the primary submission.

Repository

1. GitHub Repository

One repository containing everything: the codebase and every artefact produced along the way. Judges will read it before and during your presentation, so a clear README matters as much as clean code.

/src application code /ai prompts, agent config, guidance files /docs/requirements the spec you expanded from the brief /docs/architecture design decisions and diagrams /docs/governance review gates and the rationale for each /evals eval definitions, datasets and results /tests automated test suites /ops deployment, monitoring, token analysis README.md setup, walkthrough, decision log
Presentation

2. Presentation

A deck you will walk the panel through, covering seven things in whatever order works for your story:

  • The problem as given, and the specification you expanded it into
  • Your harness: architecture, orchestration and context management
  • Where AI leads, where a person leads, and the review gates between them
  • Your evaluation approach and what the results showed
  • A working demonstration of the solution
  • Failure handling and how the setup improved through iteration
  • Token consumption and efficiency analysis

Commit history is part of the evidence. A repository that appears fully formed in a single commit tells the panel very little about how you worked.

Tools and Frameworks

The stack is your choice. Nothing here is required and the list is not exhaustive. It is a starting point for teams who want one, and you are free to work entirely outside it if you can justify the decision.

Models and providers

Claude OpenAI Gemini Azure AI Foundry AWS Bedrock

Agent and workflow orchestration

LangGraph CrewAI AutoGen Semantic Kernel OpenAI Agents SDK Temporal

AI-assisted coding

Claude Code GitHub Copilot Cursor Windsurf

Retrieval and data

pgvector Pinecone Weaviate Azure AI Search Elasticsearch

Evaluation and observability

Langfuse LangSmith Ragas DeepEval Arize Phoenix

Design and prototyping

Figma Excalidraw Mermaid

Testing

Playwright pytest Jest k6

Deployment and runtime

Docker Kubernetes Azure Container Apps AWS ECS Vercel

One restriction: no prompt-to-app generators

Platforms that generate a complete working application from a short prompt, such as Lovable, Bolt, v0 and Replit Agent, may not be used to produce your submission.

The reason is not that they are poor tools. It is that they collapse the requirements, design, development and testing decisions this hackathon exists to assess into a single opaque step, and what comes out is a demo rather than a system you can operate, extend or defend.

AI-assisted coding inside a real codebase is a different thing entirely and is actively encouraged. Claude Code, Copilot, Cursor and similar tools sit firmly within scope. The distinction is whether you are directing the work or accepting whatever a generator hands back.

Frequently Asked Questions

Everything you need to know about participating

Who can participate?

All Myridius employees globally, regardless of technical background. Teams decide their own structure. There is no requirement that a team be made up only of engineers. Architects, functional consultants and testers may all be relevant, and you should be ready to explain why you composed your team the way you did.

Do all teams work on the same problem?

Yes. Every team receives the same brief, which is deliberately short and incomplete. Requirement discovery, refinement and expansion are part of what is being assessed, so do not wait for clarification that is not coming. Show us how your setup handles ambiguity.

Do I need to be a developer to take part?

No, but this is an engineering-heavy challenge and every team will need people who can build. Non-technical members add most value on requirement expansion, governance design, evaluation criteria and domain research, all of which carry real weight in the rubric.

What exactly do we submit, and when?

Two things, both by end of day on 30 September 2026: access to a single GitHub repository containing your codebase and all supporting documents, and a presentation deck. The repository is the primary submission because most of what is being scored, including your prompts, evals, governance decisions and token analysis, lives there rather than in the deck.

Why does the repository matter so much?

Because a deck can describe a harness, but only the repository shows one. Your prompts and agent configuration, your eval definitions and results, your architecture decisions and your commit history are the evidence behind roughly three quarters of the rubric. A repository that appears fully formed in a single commit tells the panel very little about how you worked.

Can we use Lovable, Bolt or similar platforms?

Not for producing your submission. Prompt-to-app generators collapse the requirements, design, development and testing decisions this hackathon exists to assess into a single opaque step. AI-assisted coding inside a real codebase, using tools like Claude Code, Copilot or Cursor, is a different thing entirely and is actively encouraged.

Which AI model should we use?

Whichever you prefer. The model choice carries no marks on its own. What is assessed is how you design, orchestrate, govern and evaluate the system you build around it. That said, you should be able to explain why you chose what you chose, including where you deliberately used traditional logic instead of an LLM.

What data do we work with?

Synthetic data only, generated by your team. No connection to any real system, and no real client or customer information of any kind.

What happens when our agents fail mid-build?

That is expected, and how you respond is scored. Agents will stall, ask for input they cannot get, or run without sufficient context. Be ready to explain how you detected the failure, how you recovered, and how your instructions and prompts evolved to become more robust as a result.

Do we need to actually deploy the solution?

You need to demonstrate a credible deployment and operations approach, and production readiness is explicitly part of the rubric. A running deployment is stronger evidence than a description of one, but the panel is assessing enterprise-grade thinking rather than uptime.

Where do we get help?

Mentors will be available throughout the hackathon to help you interpret the problem statement and to offer guidance on your solution. They will not make your design decisions for you, since those are exactly what is being assessed, but they are there to unblock you when you are stuck.

Beyond that, use the dedicated Teams channel for the fastest response, or email GeniusHacks@myridius.com for anything else. Regional PoCs can help with location-specific questions.

Join the Genius Community

Registrations close 2 September 2026. It is a short window, so register early.

Start Registration

Need Help? We're Here for You

Connect with our support team and regional contacts

Support

General Inquiries

Email: GeniusHacks@myridius.com
Teams Channel: Dedicated support channel
Response Time: Within 24 hours