Inspiration

I've spent time around fintech systems and kept running into the same wall: the entire global card payment network speaks a binary language from 1987 that almost no modern developer can read. ISO-8583 is the wire protocol behind every card swipe, ATM withdrawal, and contactless payment on earth. EBCDIC is the character encoding IBM mainframes still use today. Banks pay COBOL consultants $125,000–$197,000 a year just to read these packets and write adapters for them — and those consultants are disappearing at 10% per year as the average COBOL developer is now over 55 years old.

The question that wouldn't leave me alone: what if you could drop in a raw binary packet and walk out with a production-ready OpenAPI 3.1 specification and TypeScript SDK — automatically?

That's AuraGate.

What It Does

AuraGate is an autonomous legacy wire bridge. You paste a raw hex payload — an ISO-8583 banking switch packet or an EBCDIC/CP037 mainframe buffer — and AuraGate instantly returns:

  • A decoded JSON field map with every field named and typed
  • A valid OpenAPI 3.1 specification ready for Postman, Swagger UI, or AWS API Gateway
  • A TypeScript interface ready to paste into any modern microservice
  • All of this exposed via a live REST API (3 endpoints) and a Kiro MCP server with 3 agent tools

Zero manual mapping. Zero COBOL expertise. Milliseconds, not months.

How I Built It

I built AuraGate entirely spec-first inside Kiro— the entire workflow from blank repo to deployed product was driven by Kiro's features:

Spec-driven development was the foundation. Before writing a single line of code, I created .kiro/specs/core-pipeline/requirements.md with 7 requirement groups covering codecs, error handling, PBT invariants, synthesis, and MCP. Then tasks.md organized them into a 5-wave dependency graph. Kiro read the spec and implemented each wave in the correct order without me micromanaging sequencing. The codecs came out correct on the first pass because the spec forced the right constraints upfront.

Steering docs in .kiro/steering/architecture.md defined hard guardrails: zero-copy byte parsing only, Result<T,E> discriminated unions on every decoder, no any types, pure functions, and PBT required for every codec. Kiro respected these rules across every generated file — I never had to repeat "don't use string slicing" in chat. MCP integration was the most powerful feature. The MCP server (src/mcp/server.ts) extends Kiro's own agent with three live tools: inspect_iso8583_stream, inspect_ebcdic_stream, and synthesize_microservice. During development, I could paste a hex payload into Kiro chat, call inspect_iso8583_stream directly, and see the decoded fields inline — without leaving the IDE. This collapsed the test-and-verify loop dramatically.

Agent hooks — a PostFileSave hook automatically triggers the full PBT suite whenever any .ts file is saved. Every codec edit was instantly verified against 3,000 property-based assertions without any manual npm test invocation.

Vibe coding was where the architecture was born. The initial conversation in Kiro chat — describing the problem domain — led Kiro to propose the Result<T, ParseError> codec pattern, the 5-wave dependency graph, and the decision to use fast-check for property testing. A blank repo became a complete, typed architecture plan in under 10 minutes.

The core engine uses zero-copy binary parsing via Buffer.subarray typed views — no string conversion of raw byte offsets — and a pure codec design where every decoder is a deterministic function returning Result<T, ParseError>. The property-based test suite runs 1,000 iterations per invariant, verifying both round-trip correctness and fuzz safety across 7,000 total assertions.

Challenges

The hardest technical challenge was the COMP-3 packed decimal decoder.

The hardest architectural challenge was making every decoder genuinely never throw. It's easy to say "return a Result type" — it's harder to audit every code path and confirm no exception can escape, especially under arbitrary fuzz input. The property-based tests were what caught the edge cases example-based tests would have missed.

The deployment challenge was a UTF-8 BOM character invisibly prepended to package.json by Windows — which caused Vercel's build to fail with "Unexpected token ''" because Linux JSON parsers don't tolerate the BOM. Stripping it with a targeted PowerShell write fixed the Vercel build.

What I Learned

  • Kiro's spec-driven workflow genuinely changes how you build — writing requirements before code forces clarity that prevents entire classes of bugs
  • Property-based testing is not just a testing strategy; for a codec that must handle arbitrary bytes, it's the only honest verification
  • MCP is a paradigm shift — making AuraGate's tools callable from AI agent chat turns a standalone tool into a permanent fixture in a developer's workflow

Accomplishments That I am Proud Of

The decoder never throws — and we proved it mathematically. Not just "we tested it" — we ran 1,000 iterations of arbitrary random byte arrays through every codec using fast-check property-based testing. Zero uncaught exceptions. Zero silent data corruption. For a tool that touches payment data, this is the accomplishment that matters most.

Zero-copy parsing on a binary protocol from 1987. Every byte range is read via Buffer.subarray typed views — no premature string conversion, no intermediate allocations. The same architecture a production payment switch would use.

A working MCP server that Kiro can actually call. Not a mock, not a stub — three live tools that decode real financial packets and synthesize real OpenAPI specs, callable directly from Kiro agent chat. This is the first MCP-native ISO-8583 tool in existence.

Full spec-to-production in one hackathon. Requirements → design → 5-wave task graph → codecs → PBT suite → REST API → web console → MCP server → Vercel deployment — all driven by Kiro specs and steering, all in one session. The spec-driven workflow made this possible at a pace that would have been impossible with traditional tooling.

An investor-grade business case backed by real data. The docs/ folder contains a full PRD, SSR, user stories, competitive analysis, unit economics, and a 12-month financial projection with cited market research — because AuraGate is not a hackathon toy, it is a fundable product.


What's Next for AuraGate

SWIFT MT and ISO-20022 support. The card payment world is migrating from ISO-8583 to ISO-20022 for cross-border transactions — but the migration will take years and both formats will coexist. AuraGate's next codec module will decode SWIFT MT messages and generate the OpenAPI diff between old and new formats, giving banks a visual migration roadmap.

Hosted SaaS with team collaboration. The current version is self-hosted. v2.0 is a cloud dashboard where teams can save decoded packets, annotate fields, share specs with colleagues, and track their field dictionary over time — with Starter ($49/month), Growth ($299/month), and Enterprise ($1,500+/month) tiers.

CI/CD pipeline plugin. A GitHub Actions step that automatically decodes a sample packet, validates the generated OpenAPI spec, and fails the build if the wire format changed unexpectedly. Legacy system integration testing, automated.

AI-assisted field annotation. Today AuraGate names fields from the standard ISO-8583 dictionary. Next, it will use an LLM to suggest business-level descriptions for proprietary private fields (Field 48 sub-fields, custom TLV data) — bridging the gap between technical wire format and business documentation.

NACHA ACH file decoder. The US ACH network processes over $80 trillion per year through fixed-width COBOL-era flat files. AuraGate will extend to decode NACHA ACH files and generate REST API specs from batch transaction records.

Enterprise on-prem deployment. Banks cannot send production packet samples to a cloud service. AuraGate will offer a Docker-based on-prem deployment with air-gap support, allowing compliance teams to run the decoder inside their own network perimeter.

The core engine is open source and will stay that way. AuraGate's mission is simple: no developer should need a COBOL consultant just to read a payment packet.

Built With

  • api
  • cobol
  • ebcdic
  • express.js
  • fast-check
  • financial
  • iso-8583
  • kiro
  • mainframe
  • mcp
  • modernization
  • node.js
  • openapi
  • property-based
  • rest
  • testing
  • typescript
  • vercel
Share this project:

Updates

Submission history