Department of Social Services

The Cashless Debit Card: automated product-level blocking software

Important dates

Opportunity ID
Deadline for asking questions
Tuesday 20 June 2017 at 5PM (in Canberra)
Closing date for applications
Tuesday 27 June 2017 at 5PM (in Canberra)
Tuesday 13 June 2017


Write a summary of your brief

The Cashless Debit Card (CDC) restricts the purchase of alcohol, gambling and access to cash and cash-equivalent products. To support the CDC, the Department of Social Services is seeking a software solution that will allow for automatic product level blocking at the Point of Sale.

What is the latest start date?
How long is the contract?

The software should be ready by October 2017. However, the contract will run until 30 June 2019.

Where can the work take place?
Who will the specialist work for?
Department of Social Services
Budget range


About the work

Why is the work being done?

The Government is committed to reducing the social harm caused by welfare fuelled alcohol, drug abuse and gambling. The Cashless Debit Card (CDC) aims to achieve this by reducing the amount of welfare that can be spent on alcohol and gambling, and cash that could be spent on drugs. The CDC is also testing the commercial delivery of welfare payments.

The trial commenced on 15 March 2016 in Ceduna, South Australia and on 26 April 2016 in Kununurra and Wyndham, Western Australia. These locations were chosen on the basis of high levels of welfare dependence and where gambling, alcohol and/or drug abuse were causing unacceptable levels of harm within the community. On 14 March 2017, the CDC in both locations was extended. As part of the 2017/18 Budget, the Government announced the expansion of the CDC to two additional locations. A decision on these locations has not yet been made.

What's the key problem you need to solve?

The CDC seeks to restrict the sale of alcohol, gambling and cash-equivalent products (restricted goods). This is primarily done by Indue Ltd (the issuer of the CDC) using Merchant Category Code blocking.

The real challenge is mixed merchants – those that sell a mix of restricted and unrestricted goods. For mixed merchants, for example a bar and bistro, Indue engages with these merchants to enter into a contract to refuse the sale of restricted goods to anyone using the CDC. In practice, this generally requires the register operator to manually sight the card and refuse the sale of restricted goods.

Both of these options present opportunities for non-compliance and workarounds.

The objective of the procurement is to engage a provider who can develop a merchant management solution that would automatically prevent the sale of restricted goods at the Point of Sale (POS). The provider would be required to develop the software solution; implement and deliver the software to mixed merchants in either existing CDC trial locations or in the expansion locations; and manage the software for the length of the contract (expected end date 30 June 2019). Where possible, the software should be able to be introduced onto existing POS terminals.

Describe the users and their needs

Merchants would be the primary user of your product. Customers will also be using the software but the solution should provide a seamless experience for CDC participants at the POS and not require participants to interact outside of the typical customer experience.

What work has already been done?

In the existing CDC locations there are 49 mixed merchants in Ceduna and 47 in the East Kimberley.

It is anticipated that the new CDC locations will be regional with a larger merchant footprint than in the current locations. Market scope and reach will be confirmed once Government has made a decision on the future location/s of the CDC.

Who will the work be done with?

You would be primarily working with representatives from the Department of Social Services (DSS). DSS will be responsible for contract management, project management and identifying and engaging with mixed merchants where the software would be installed. You would also be responsible for working with the mixed merchants who would be using the software. Depending on your proposal, you may be required to work with Indue Ltd.

Any additional relevant information?

CDC participants are issued a dual branded Visa/EFTPOS Debit Card by Indue Ltd that has a unique Bank Identification Number (BIN). The Card is linked to an underlying individual bank account.

The Marketplace Brief is stage one of a two stage process. In stage one, suppliers will be assessed on their ability to meet the required skills listed under Essential Skills and Experience. This stage will be used to create a shortlist of suppliers.

In stage two, shortlisted suppliers will be contacted and provided with a formal Request for Quotation (RFQ). The RFQ will include further detail around technical specifications as well as detailed evaluation criteria. The criteria listed under Proposal Criteria are an indication of how the RFQ will be evaluated.

Shortlisted respondents may be requested to provide a presentation to the Evaluation Committee on their proposal.

Note: Value for money will be a separate factor of the final RFQ evaluation and technical competence will be weighted according to particular requirements. This will be detailed in the formal RFQ. The weighted evaluation criteria of this Brief are not reflective of the weighted criteria likely to be used to assess the RFQ.

What phase is the work in?

Work setup

Where will the work take place?

There are no limits on where the software development can take place. The software solution may be implemented in and around the existing CDC sites (Ceduna and the East Kimberley) as well as the CDC expansion sites, which are yet to be determined. Tenderers should provide a solution that will achieve the same outcome regardless of where the software is implemented. To assist with pricing it should be assumed there will be a range of merchants that would need to use the software including petrol stations, grocery stores and hospitality outlets.

What are the working arrangements?

Where possible, work would take place at the tenderer’s usual place of business. The successful tenderer may be required to travel to the locations where the software will be implemented, if the work cannot be undertaken remotely.

Is security clearance required?


Additional information

Additional terms and conditions

The work order will be modified to include additional terms and conditions which will be largely based on the SourceIT Contract. The SourceIT Contract is part of the Commonwealth Contracting Suite available on the Department of Finance’s website.

Specific provisions likely to be included in addition to the Master Agreement are:

- Clause 3: Duration of Contract

- Clause 6: General Obligations of the Parties

- Clause 8.13: Privacy

- Clauses 8.14 and 8.15: Anti-discrimination and Work Health and Safety

- Clause 8.17 Maintenance of records

- Clause 8.18 Cooperation with other service provider

- Clause 8.19 Harmful code warranty

- Clause 11: Acceptance (specifically cl 11.7: Failure of an acceptance test and cl 11.8: Supplementary tests)

- Clause 12: Warranties – Contractor

- Clause 15: Non-disclosure and Use of Information

- Clause 16: Protection of Personal information

- Clause 18: Third Party Indemnity

- Clause 20: Liability

- Clause 24: Disengagement

- Clause 29: Software development (specifically cl 29.2: Preparation of project plan, cl 29.3: Approval of Project Plan, cl 29.4: Preparation of Design Specification, cl 29.5: Approval of Design Specification, cl 29.6: Methodology and cl 29.7(b): Source code)

- Clause 31: Software support

In addition to the above, under s95B of the Privacy Act 1988, agencies must, when entering into a Commonwealth contract ‘take contractual measures to ensure that a contracted service provider for the contract does not do an act or engage in practice that would breach an Australian Privacy Principle if done or engaged in by the agency’.

The Department is also likely to include clauses surrounding Performance Representations and Warranties.

Skills and experience

Buyers will use the essential and nice-to-have skills and experience to help them evaluate sellers’ technical competence.

Essential skills and experience
  • have experience in developing and administering POS software
  • have experience in integrated POS terminals
  • have experience working with financial technology
  • provide a software solution that can identify products at the basket or SKU level
  • provide a software solution that will block restricted goods (alcohol, gambling and cash-equivalent products like open loop gift cards) with the CDC in real time at the POS
  • provide a software solution that can be used across different POS operating systems and ‘smart’ terminals
  • be able to provide regular reporting to DSS on the effectiveness of the software in blocking restricted goods and not prohibiting the purchase of non-restricted goods
  • provide a solution that complies with any legislative and regulatory requirements including International and Australian standards
Nice-to-have skills and experience

How sellers will be evaluated

How many shortlisted sellers will you evaluate?
Proposal criteria
  • Ability to meet time frames (i.e. October implementation)
  • Approach and methodology
  • Ability to achieve the objectives
  • Ability to fulfil the reporting requirements
  • Confidentiality in communication and security
Cultural fit criteria
Payment approach
Time and materials
Assessment methods
  • Written proposal
  • Presentation
Evaluation weighting

Technical competence

Cultural fit


Seller questions

Seller questions
Seller question Buyer answer
1. So you need a solution which integrates with a number of different Point of Sale systems, potentially with a variety of different SKU's for the possible blocked products/services - I'd envisage we'd need to create bespoke middleware software to talk to each individual POS - thoughts? The software developed would have to be cross-compatible across different Point of Sale (POS) systems. We understand that there are a variety of different POS operating systems and that unintegrated POS systems (i.e. where the EFTPOS terminal is separate to the POS) may be out of scope for this solution. In terms of identifying restricted goods, the Department envisions this would likely involve the use of Universal Product Codes (UPC).

Interested in this opportunity?

Before you can apply for this opportunity, you need to:

  1. Register to join the Marketplace.
  2. Submit a case study and pricing and check your documents are up-to-date.
  3. Request an assessment of your chosen case study.