Oct 21, 2026 by BeMyApp
Financial institutions have no shortage of ideas for improving digital banking, payments, fraud prevention, customer experiences, and financial technology. Turning those ideas into working solutions, however, can be difficult when innovation has to operate within strict regulatory and security requirements.
Hackathons can provide a structured way to explore new ideas without treating compliance as something to address later.
For financial services organizations, the most effective hackathons bring developers, business teams, security specialists, and subject matter experts together around a defined challenge. The goal is not simply to build something quickly. It is to explore what is technically possible while understanding the requirements that a solution would need to meet before moving toward real-world use.
Hackathons give financial institutions a way to experiment with technologies and ideas that may be difficult to explore through traditional development processes.
A focused event can bring together internal teams, developers, startups, technology partners, and other participants to work on specific challenges. Organizing a hackathon like this starts with defining that challenge clearly.
Common areas for financial services hackathons include:
A hackathon can also help organizations evaluate how new technologies could address a particular business problem before committing significant resources to a larger development project.
A financial services hackathon cannot always run on the same assumptions as a general technology event. Financial institutions handle sensitive financial and personal information, operate within regulatory frameworks, and often have established security and risk-management requirements.
Here is where the difference shows up most:
|
Aspect |
General Tech Hackathon |
Financial Services Hackathon |
|
Data |
Often uses real or public data |
Typically uses synthetic or anonymized data instead of live customer information |
|
Rules |
Fewer formal requirements |
Regulatory, security, and risk requirements to plan around |
|
Participants |
Often open to a wide audience |
May be limited based on data access and risk |
|
Judging |
Often centered on creativity and execution |
Also considers feasibility within regulation |
|
After the event |
A prototype can often move straight into development |
May need compliance and security review first |
Who takes part is one of the biggest differences, since an event built around internal teams carries different risks than one open to outside developers and fintech partners. It is worth thinking through the right format for your goal before you commit.
These constraints do not necessarily prevent experimentation. They give participants a defined space to explore ideas without creating unnecessary operational or compliance risks.
Before planning one, it helps to understand the pieces that make it work. Five components shape every compliant hackathon, regardless of the order you tackle them in:
A broad prompt such as "reinvent banking" can generate interesting ideas, but it can make it difficult to evaluate whether projects address a meaningful business problem.
Financial services organizations get more useful results by defining a specific challenge. For example:
The challenge should give participants enough room to develop different approaches while providing a clear connection to the organization's goals.
Compliance should not be treated as a final checkpoint after a prototype has already been built. Before the event begins, organizers should identify the requirements that could affect the projects participants create.
These may include:
The specific requirements will depend on the institution, jurisdiction, technology, and use case. The purpose is not to turn the hackathon into a compliance exercise. It is to give participants enough guidance to develop ideas within a realistic environment.
Data is one of the biggest considerations in a financial services hackathon. Real customer data can introduce unnecessary privacy and security risks, particularly when participants include external developers or partners. Instead, organizations can consider using:
These resources give participants enough information to demonstrate how a solution might work without exposing sensitive production data. A controlled environment also makes it easier for security and technical teams to monitor access throughout the event.
Participants need enough technical access to build meaningful prototypes. For a financial services hackathon, this could include APIs, SDKs, documentation, test accounts, sandbox environments, datasets, or development tools.
Access should be planned before the event. If developers spend most of the hackathon waiting for credentials, troubleshooting unclear API permissions, or trying to understand undocumented requirements, less time is available for solving the actual challenge. Technical documentation and support should be part of the event design rather than an afterthought.
The same goes for the event platform itself. Participants need one place to register, join teams, reach mentors, and submit projects. Building or procuring that from scratch is a significant lift inside a bank, which is why many institutions run their programs on an existing platform.
Bring together developers and participants with the business, technical, security, and compliance knowledge the challenge needs.
Compliance and security teams do not have to sit on the sidelines until projects are submitted. Involving them throughout the event, not only at the end, helps participants understand constraints while they are still developing their ideas. Experts can help answer questions about:
This involvement can also help teams identify promising ideas that might otherwise get dismissed because the requirements seemed too complex. The role is not to approve every prototype for production; it is to provide the expertise that makes experimentation more realistic.
A financial services hackathon should not judge projects solely on how impressive the final demonstration looks. Decide how projects will be judged before the event begins, using criteria such as:
Clear criteria give participants a better understanding of what the organization values and help judges compare projects consistently.
To make this concrete, here are challenge themes financial institutions commonly run, each tied to a real business problem rather than a broad slogan. They are a useful starting point for shaping your own.
Ask teams to build tools that flag anomalies, score transactions for risk, or spot fraud patterns in real time. It is one of the most common financial services themes because the business value is immediate and easy to evaluate.
Challenge participants to simplify account opening and identity verification using approaches like biometrics, document scanning, or real-time checks, with the constraint of reducing friction without weakening compliance. A strong brief here balances speed against security controls.
Focus on faster, cheaper, or smarter payments: real-time transfers, cross-border flows, request-to-pay, or embedded payments. Open banking APIs give teams a rich sandbox to build against.
Have teams turn transaction data into useful guidance, such as spending breakdowns, cash-flow forecasting, savings nudges, or budgeting tools. This theme works well for improving customer experience in a mobile app.
Challenge participants to widen access to financial services for underserved groups, through alternative credit scoring, low-bandwidth or multilingual interfaces, or tools for people new to formal banking.
Ask teams to apply AI to support agents, customer chat, or internal workflows, with a clear boundary around how sensitive data is handled. A good version of this challenge pairs an AI goal with an explicit privacy constraint.
Have teams build features that surface the environmental impact of spending or support green financial products, a theme a growing number of banks now run.
The pattern across all of these is the same. Each starts from a specific business problem, fits inside clear data and compliance boundaries, and produces something you can evaluate against real criteria rather than a vague "innovation" goal.
Many of the planning steps above get easier once an institution stops treating each hackathon as a one-off project.
Morgan Stanley has run its Code to Give hackathon program on the BeMyApp platform for the past four years, hosting four hackathons a year. Code to Give pairs students and early-career technologists with Morgan Stanley mentors to build prototype solutions for nonprofit partners.
The 2026 Asia edition, for example, ran as a hybrid event across Hong Kong and Singapore. It opened with a virtual kickoff, gave teams four days to build remotely, and closed with an in-person finale where teams presented demos and pitches to a panel of judges.
Running at that pace depends on infrastructure that is already in place. Registration, team assignments, mentor communication, project submissions, and judging all run through one platform under Morgan Stanley’s brand. Each new event starts from a working setup instead of a new build.
That matters more in banking than in most industries. Adopting a new external-facing tool inside a financial institution usually means vendor risk assessment, IT security review, and procurement, and that process can take longer than planning the event itself. Once a platform is in place, every future event can use it. Organizers get a consistent process they can repeat across regions, formats, and years.
If you are planning a recurring program rather than a single event, the platform decision is worth making early.
Knowing the components is one thing. Getting the event onto the calendar and actually running is a separate project, with its own timeline and its own set of decisions.
In a regulated environment, legal, security, and compliance sign-off is usually the longest lead time in the whole project, often longer than booking a venue or lining up mentors. Loop in these teams while the challenge is still being scoped, not after it is finalized, so their feedback shapes the event instead of delaying it. A hackathon planned on a six-week timeline can easily stall for two of those weeks waiting on an approval that could have started on day one.
A financial services hackathon usually needs sign-off above the organizing team, both for budget and for the authority to grant data and system access. An executive sponsor also makes it easier to get compliance, security, and business stakeholders to prioritize the event instead of treating it as optional.
In-person, virtual, or hybrid changes almost everything downstream: what data access is practical, how participants collaborate, what the budget looks like, and how far you can reach for outside talent. Decide this early, since it affects venue, platform, and recruitment decisions that follow.
If the event includes outside developers, students, or fintech partners, recruitment needs lead time of its own. That includes deciding where to promote the event, what the application or registration process looks like, and how to communicate the event's purpose clearly enough to attract people who can actually contribute to the challenge. Internal-only events still need promotion, since employee participation is rarely automatic.
Participants should receive the data boundaries, access rules, and evaluation criteria before the event starts, not as a surprise once they begin building. A short written brief covering what data they can use, what tools they have access to, and how projects will be judged prevents wasted effort and reduces the number of questions your compliance and security experts have to field live during the event.
Decide who reviews prototypes, who it reports to, and what the criteria for moving a project forward will be, before the hackathon starts. Without an owner named in advance, promising ideas tend to stall in the gap between the closing ceremony and whoever eventually follows up. Capturing that value depends on measurement, so it also helps to decide early how you will measure the ROI of the program.
Running a hackathon in a regulated environment is also where many institutions weigh doing it in-house against bringing in a partner. If that is a live question for you, it helps to understand the true cost of a DIY developer event versus an agency.
If you decide a partner is the right call, knowing what to look for matters even more in a regulated setting, where the wrong choice carries compliance risk on top of the usual cost of a bad fit.
For financial services organizations, a well-designed hackathon can create a controlled environment where developers and business teams explore new ideas while working within clearly defined technical, security, and regulatory boundaries.
The most valuable outcome may not always be a production-ready application. It can be a validated concept, a new approach to a business problem, or a clearer understanding of how an emerging technology could fit into the organization's future.
For organizations that want to run structured innovation programs, BeMyApp helps plan and run hackathons end to end, covering the technical execution and developer engagement these initiatives require. If you are considering one, see how we can help you organize your hackathon.
AI Builders Challenge with IBM Bob 2026 — Meet the Winners
Oct 20, 2026 by
Xylem Global Student Innovation Challenge 2026
Oct 19, 2026 by