Issuer and processor
Cuscal, ASL
- Manufactures and personalises
- Connects to Visa and Mastercard
- Authorises and settles
- Holds the PAN and the PIN
Your bank runs two systems. Neither one manages card linkage.
Moroku Card Services is the service in between. One API for every card operation, with staff and customer permissioned on the same product.
On Cuscal today, in Moroku Money mobile and internet banking. Built to run on any issuer and any core.
Teller consoleContact centre, fraud and risk
Moroku MoneyMobile and internet banking
The bank carries this today
Moroku Card Services
Domain model, permissions, approvals, audit, connectors
IssuerCuscal, ASL
CoreTemenos, Mambu, Thought Machine, Fiserv
The solution gap
Two systems already exist. Neither of them manages card linkage. Your issuer manufactures the cards and authorises the transactions, your core holds the customer and the money, and everything in between falls to you.
The bank
The part your staff spend their day on
- The request and the approval
- Which card belongs to which account
- The fee, the waiver, the dispute
- Who did what, on whose authority
Core banking
Temenos, Mambu, Thought Machine
- Holds the customer
- Holds the accounts and balances
- Holds the mandates
- Posts the money
The bank's view of its own cards lives in the gap.
One API, two permission models
The teller console and Moroku Money call the same endpoints. What differs is the permission model, and therefore the scope.
Staff
Teller, contact centre, card operations, fraud and risk
- Your staff identity provider, OpenID federated
- Claims carry the staff member's role
- An on behalf of permission model
- Any card, subject to the permission matrix
Customer
Moroku Money, mobile and internet banking
- Cognito, scoped to their own cards
- Their own cards only
- The session covers standard actions
- Step up for lost, stolen, PIN and closure
One permission matrix. Evaluated server-side. For both.
The API tells each client what it may do, so a client can never offer an action the service will refuse. Staff and customer have separate permission models, evaluated by the same engine. That is what stops the two experiences drifting apart, and it is the difference between a service and two integrations.
The teller console
Task-shaped, not data-shaped. The customer on the left, the card in the centre, and an action rail on the right derived from the permission matrix.
The customer on the leftIdentity and their cards, held in context for the whole call.
The card in the centreStatus, controls, limits, wallets and recent activity on one screen.
The action rail on the rightDerived from the permission matrix, so it shows what this staff member may actually do.
Who owns what
Card Services is not a second system of record. It mirrors the issuer and connects the two systems you already run.
| Issuer and processorCuscal, ASL | Core bankingTemenos, Mambu, Thought Machine | Card servicesMoroku |
|---|---|---|
| PAN, CVV, expiry and chip data | Customer and accounts | Which card belongs to which account |
| Production, personalisation and mailing | Balances and postings | Lifecycle workflow and approvals |
| Authorisation and scheme routing | Mandates and account authorities | Who did what, when, on whose authority |
| Card status, authoritative | Fee postings and the ledger | One API contract for every channel |
| PIN services | The audit artefact |
Connectors, not dependencies
Both external systems sit behind a narrow interface the service owns. A different sponsor is a connector. A different core is a connector. Neither is a rebuild.
Issuer
Eleven operations
orderCard changeStatus getCard listAuthorisations setControls resetPin unblockPin listTokens changeTokenStatus lodgeDispute
Core banking
Eight operations
getCustomer getAccountsForCustomer getAccount getAccountPostings checkMandate postFee reverseFee subscribe
Every connector passes the same conformance suite, which turns an open-ended integration into a definite one. Moroku's model bank is the reference implementation, so the whole service runs, demonstrates and tests with no client environment behind it.
BIN and processor lock-in is the largest switching cost in an Australian card programme. Changing processors means a BIN transfer negotiated with the scheme and the outgoing sponsor, or reissuing every card in the portfolio. Which is exactly why processor roadmaps move at the pace they move.
Cuscal absorbs Indue
The ACCC did not oppose. The domestic incumbent now holds most of the mutual sector.
Banking Circle completes ASL
A foreign-owned payments bank with a domestic ADI licence enters as a real alternative.
A bank has a genuine choice
And the thing that makes the choice expensive is channel integration depth against one processor.
No PAN. No CVV. No PIN. Anywhere with us.
An isolated deployment with tokenisation. There is no reveal control in either front end, and there is no plan to add one.
What the service holds
An issuer reference, field-level encrypted. CVV and PIN are encrypted at source and pass straight through to the issuer.
What staff can see
Every PIN operation is an instruction to the issuer to run its own flow. A teller never learns a PIN.
What this buys the bank
One security posture across both front ends, customer and staff, rather than two to defend separately.
If a workflow appears to need the PAN, the workflow is wrong. Any future need is met by an issuer-hosted component, never by widening this one.
What it does
The specified surface, with a permission matrix behind every item.
Issuance
- Order new and additional cards
- Replace lost, stolen or damaged
- Delivery and tracking
- Activation
Status
- Lock and unlock
- Fraud restriction
- Close
- Renewal
Controls
- Online, overseas, ATM
- Contactless and magnetic stripe
- Gambling block
- Limits
PIN
- Set and reset
- Step-up one-time code
Wallets
- Apple, Google and Samsung
- Add, suspend, resume, delete
Disputes
- Lodge several transactions at once
- Reference and tracking
Approvals
- Spend limits
- Dual authorisation queue
Your cards, your channels, your choice of who processes them
One service. One permission model. One audit trail. Every channel, and any issuer behind it. We can show you the console running against a real core, with no environment of yours involved.